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EXECUTIVE  SUMMARY 


The  Chief  of  Engineers  has  designated  the  Engineer  Studies  Center  (ESC) 
as  the  Center  of  Engineer  Modeling  for  the  US  Army  Corps  of  Engineers  (USACE) 
and  the  USACE  point  of  contact  for  the  Army  Model  Improvement  Program  (AMIP) . 
As  such,  ESC  has  evaluated  the  current  status  of  combat  engineer  modeling, 
identified  a  number  of  deficiencies  in  combat  engineer  modeling,  and  prepared 
this  Engineer  Model  Improvement  Program  (EMIP)  Plan  which  is  designed  to 
correct  those  deficiencies. 

The  initial  focus  of  ESC's  effort  was  on  the  fully  automated  models, 
including  CASTFOREM,  VIC,  and  FORCEM.  ESC  concentrated  on  these  models  first, 
believing  that  results  of  these  efforts  would  have  the  most  immediate  payoff 
in  force  structuring  and  unit  design  initiatives.  ESC  also  believed  that 
improvements  to  the  fully  automated  analytic  models,  when  completed  and 
approved,  could  be  transferred  fairly  easily  to  the  interactive  and  training 
models.  More  specifically,  ESC  addressed  the  following  questions: 

*  Does  the  structure  of  the  models  adequately  represent  the  effects 
of  engineer  task  execution? 

*  Does  the  model  represent  engineer  task  execution  on  the 
battlefield,  and  can  the  requirements  for,  or  capabilities  of,  an 
engineer  force  be  measured? 

*  Does  the  model  use  the  quality  and  quantity  of  digitized  terrain 
data  needed  to  adequately  measure  the  influence  of  terrain  on  the 
outcome  of  the  battle? 

ESC's  study  found  that  until  1979,  the  quality  of  engineer  modeling  was 
not  good.  This  was  because  engineer- related  studies  were  never  high  enough  in 
priority  relative  to  other  studies  in  the  Army's  study  program.  Consequently, 
engineer  representation  in  the  Army's  analytical  models  received  little,  if 
any,  formal  attention  from  the  Army's  analytic  community.  However,  in  1979  an 
Army  Model  Improvement  Program  (AMIP)  was  initiated  to  improve  and  integrate 
the  development,  documentation,  and  implementation  of  a  hierarchical  family  of 
computerized  combat  models.  One  rationale  for  the  creation  of  AMIP  war,  to 
ensure  that  the  hierarchy  of  combat  models  properly  represented  functional 
areas.  In  particular,  the  models  were  to  simulate  combat,  combat  support,  and 
combat  service  support  in  an  adequate,  valid,  and  consistent  manner.  This 
program,  coupled  with  the  US  Army  Engineer  School's  (USAES)  own  Engineer 
Modeling  Program,  helped  to  improve  the  situation.  In  fact,  engineer  modules 
were  developed  for  each  level  of  the  AMIP  hierarchy. 

Despite  these  improvements,  a  number  of  problems  still  exist.  Foremost 
among  these  are: 

*  The  Army  land  combat  models  do  not  adequately  demonstrate  the 
contribution  that  combat  engineers  make  to  the  outcome  of  the 
battle . 
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*  The  Army  land  combat  models  do  not  adequately  measure  the  size  of 
the  engineer  force  needed  to  support  the  battle. 

*  The  availability  of  digital  terrain  data  (DTD)  is  not  adequate  to 
support  the  Army's  analytic  community. 

To  correct  these  and  other  problems,  ESC  has  developed  this  Engineer 
Model  Improvement  Program  (EMIP)  plan.  This  plan  provides  a  complete  discus¬ 
sion  of  the  quality  of  engineer  modeling  within  the  hierarchy  of  Army  models, 
an  identification  of  what  engineer  modeling  improvements  are  needed  (including 
terrain  representation),  and  an  assessment  of  which  agency  or  activity  is 
perhaps  most  appropriate  and  best  equipped  to  make  those  improvements.  This 
plan  also  provides  a  "best  estimate"  of  how  much  analytic  effort  will  be 
required,  the  dollar  cost  of  that  effort,  and  when  the  Army  can  expect  the 
improvements  to  be  achieved.  This  EMIP  Plan  is  therefore  more  than  a  plan;  it 
is  a  strategy  or  direction  for  the  engineer  and  the  analytic  communities  to 
follow  over  the  next  few  years.  Major  elements  of  this  plan  include i 

*  Some  changes  to  CASTFOREM  to  improve  its  combined  arms 
representation . 

*  Some  major  changes  to  VIC  to  expand  the  number 

of  engineer  tasks  and  effects  that  VIC  represents. 

*  A  new  FORCEM  engineer  module,  in  addition  to  changes  in  existing 
FORCEM  elements. 

*  The  development  of  an  engineer  functional  area  model  (EFAM) . 

*  The  production  of  interim  DTD. 

*  An  analysis  of  engineer  task  effectiveness. 

From  the  beginning,  ESC  believed  that  the  representation  of  engineer 
forces  within  the  hierarchy  of  Army  models  could  best  and  most  consistently  be 
achieved  by  a  centralized  program  that  represented  the  views  of  the  senior 
engineer  leadership.  However,  ESC  also  believed  that  a  centralized  program 
must  be  developed  in  coordination  with  the  Army  modeling  community  and  be 
fully  supported  by  the  Army  Models  Committee.  It  is  for  these  reasons  that 
ESC  has  developed,  staffed,  and  gained  the  engineer  and  Army  analytic  com¬ 
munities'  approval  of  this  EMIP  plan.  It  has  been  designed  to  enrich  the 
combat  realism  of  the  AMIP  models.  It  is  not  intended  to  overburden  any  model 
with  unnecessary  detail.  As  such,  ESC  has  carefully  considered  the  impact  of 
its  recommendations  on  each  specific  model  and  feels  that  the  recommended 
changes  are  appropriate  and  desirable  to  the  Army  community  as  a  whole;  not 
just  the  engineer  community.  Implementar irn  of  this  plan,  therefore,  is  in 
the  best  interest  of  the  US  Army. 
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THE  ENGINEER  MODEL  IMPROVEMENT  PROGRAM  PLAN 

I .  INTRODUCTION 


1.  Purpose .  The  Engineer  Model  Improvement  Program  (EMIP)  is  a 
comprehensive  effort  that  is  designed  to  ensure  that  engineers  are  properly 
represented  in  the  Army's  land  combat  models.  This  paper  outlines  a  plan  that 
was  developed  by  the  US  Army  Engineer  Studies  Center  (ESC)  to  initiate  and 
manage  that  program.  This  plan  was  developed  in  support  of  the  US  Army 
Engineer  School  (USAES)  and  in  conjunction  not  only  with  the  USAES ,  but  also 
the  broader  "engineer  community"  and  the  affected  Army  "analytic  community." 

2.  Scope .  This  plan: 

a.  Identifies  the  problems  associated  with  engineer  representation 
in  current  Army  models. 

b.  Identifies  and  prioritizes  the  work  required  to  correct  these 

problems . 

c.  Schedules  this  work  over  a  4-year  period,  with  emphasis  on 
completing  the  critical  tasks  within  2  years. 

d.  Estimates  the  analytic  effort  required,  and  displays  annual 
funding  and  manpower  requirements. 

e.  Addresses  the  question  of  who  is  available  to  do  the  work. 

3 .  Background . 

a.  The  Army  Model  Improvement  Program  (AMIP) .  In  1979,  the  Review 
of  Army  Analysis  found  several  deficiencies  in  the  Army's  computerized  combat 
models:  poor  documentation,  poor  response  to  study  needs,  inconsistent 

results,  differing  data  assumptions,  lack  of  interface  structure,  and  limited 
(or  no)  functional  area  representation . ^  As  a  result,  a  directive  was  imple¬ 
mented  for  an  Army  Model  Improvement  Program  (AMIP)  in  April  1980.  Tasks  and 
responsibilities  within  the  AMIP  are  described  in  Army  Regulation  (AR)  5-11.2 
(1)  The  goals  of  the  AMIP  were  to  improve  the  Army's  analytical 
capability,  improve  model  consistency  and  responsiveness,  establish  data  base 
design  and  management,  apply  emerging  computer  technology,  develop  training 
applications,  and  stem  model  proliferation.  These  goals  were  to  be 
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accomplished  by  developing,  documenting,  and  implementing  a  hierarchical 
family  of  computerized  combat  models  which  are  supported  by  functional  area 
models  (as  shown  in  Figure  1) . 

(2)  Headquarters,  Department  of  the  Army  delegated  primary 
responsibility  for  overseeing  AMIP  activities  to  the  Commanding  General,  US 
Army  Training  and  Doctrine  Command  (CG,  TRADOC).  An  AMIP  Management  Office 
(AMMO)  was  established  to  assist  in  coordinating  and  directing  AMIP  acti¬ 
vities.  AMIP  advice  and  guidance  were  to  be  provided  by  the  Army  Models 
Committee  (AMC) ,  which  was  formed  in  1981  as  a  continuing  committee.  The 
chairperson  of  the  AMC  is  the  Deputy  Under  Secretary  of  the  Army  for  Opera¬ 
tions  Research. 

(3)  The  USAES  was  designated  by  the  CG ,  TRADOC ,  to  be  the 
engineer  proponent  for  AMIP  modeling  efforts.  As  such,  the  school  has  had  the 
overall  responsibility  of  ensuring  that  the  engineer  functional  area  is 
properly  represented  in  the  AMIP  models. 

b.  US  Army  Corps  of  Engineers'  (USACE)  involvement  in  AMIP.  USACE 
has  been  involved  primarily  in  a  support  role.  As  such,  it  has  provided  model 
development  resources  to  USAES  and,  in  turn,  the  Army  modeling  community. 

Both  the  Construction  Engineering  Research  Laboratory  (CERL)  and  the  Waterways 
Experiment  Station  (WES)  have  had  engineer  modeling  programs,  some  of  which 
pre-date  the  1980  establishment  of  AMIP.  Thus,  combat  engineer  modeling  has 
been  a  high  priority  effort  in  USACE,  especially  in  their  research  and 
development  programs. 

c.  ESC  involvement  in  AMIP.  ESC's  involvement  with  AMIP  began  in 
the  fall  of  1985.  During  October  and  November  of  that  year,  a  series  of 
messages  was  sent  by  USAES,  USACE,  and  the  TRADOC  Analysis  Command  (TRAC),  all 
in  reference  to  a  possible  increase  in  the  engineer  staff  at  HQ  TRAC.  The 
primary  objective  was  to  help  TRAC  model  the  value  of  engineers  as  members  of 
the  combined  arms  team.  As  a  result,  USACE  proposed  to  assign  an  engineer 
officer  to  ESC,  with  duty  station  at  HQ  TRAC.  The  mission,  functions,  and 
operating  procedures  associated  with  this  new  position  were  formally  agreed  to 
in  a  12  June  1986  Memorandum  of  Understanding  between  the  Commandant,  USAES 
and  the  deputy  commanding  generals  of  both  TRAC  and  USACE  (see  Annex  G) .  In 
August  1986,  a  former  engineer  battalion  commander  was  selected  to  fill  this 
newly  created  position. 
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AMIP  MODELS 


(1)  USACE  went  beyond  simply  stationing  one  ESC  officer  at  Fort 
Leavenworth.  The  CG ,  USACE,  also  assigned  ESC  a  combat  engineer  modeling 
mission.  ESC's  experience  with  worldwide  engineer  assessments,  evaluation  of 
engineer  unit  designs,  and  evaluations  of  engineer  doctrine  placed  it  in  a 
unique  position  to  be  a  focal  point  for  USACE  modeling  support.  To  this  end, 
on  3  December  of  1986  the  CG ,  USACE,  also  assigned  to  ESC  the  following 
missions : 

(a)  Monitor  and  evaluate  the  representation  of  engineers 
within  the  hierarchy  of  Army  models  and  provide,  in  coordination  with  USAES , 
recommendations  to  the  AMC . 

(b)  Provide  primary  USACE  interface  with  the  AMMO  and 
other  AMIP  organizations  on  matters  relating  to  engineer  modeling. 

(c)  Serve  as  the  USACE  point  of  contact  for  the  Army  Staff 
on  all  matters  pertaining  to  AMIP  engineer  modeling. 

(d)  Serve  as  USACE  program  manager  for  AMIP  engineer  model 
improvements  provided  by  USACE  laboratories. 

(2)  To  clearly  delineate  ESC's  relationship  with  the  USAES,  the 
CG,  USACE,  specifically  highlighted  the  following: 

The  designation  of  ESC  as  the  Center  of  Combat  Engineer 
Modeling  within  USACE  is  intended  to  strengthen  the 
engineer  community's  involvement  in  modeling.  This 
designation  does  not  circumvent  the  duties  and  respon¬ 
sibilities  of  the  USAES  as  the  Engineer  Proponent  with 
its  prescribed  responsibilities  under  TRADOC  for 
modeling.  ESC's  AMIP  work  and  modeling  initiatives 
will  be  fully  coordinated  with,  and  concurred  in,  by 
the  USAES. 3 

d.  ESC's  involvement  in  the  Engineer  Model  Improvement  Program 
(EMIP) .  From  the  beginning,  ESC  believed  that  the  representation  of  engineer 
forces  within  the  hierarchy  of  Army  models  could  best  and  most  consistently  be 
achieved  by  a  centralized  program  that  represented  the  views  of  the  senior 
engineer  leadership.  However,  ESC  also  believed  that  a  centralized  program 
must  be  developed  in  coordination  with  the  Army  modeling  community  and  be 
fully  supported  by  the  AlMC .  It  is  for  these  reasons  that  ESC  has  developed, 


3Letter,  US  Armv  Corps  of  Engineers,  dated  December  7  '|9R6.  s"biect: 

Engineer  Studies  Center's  Role  in  Engineer  Modeling. 
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staffed,  and  gained  the  engineer  and  Army  analytic  coirununi tics '  approval  of 
this  EMIP  plan. 

4.  Limits .  ESC's  combat  engineer  modeling  mission  is  limited  to  those 
land  combat  models  included  within  the  hierarchy  of  Army  models.  Futhermore, 
this  EMIP  plan  focuses  only  on  improvements  that  are  needed  to  the  fully 
automated  models,  which  include  the  Combined  Arms  and  Support  Task  Force 
Evaluation  Model  (CASTFOREM) ,  the  Vector  -  in- Commander  (VIC)  model,  and  the 
Force  Evaluation  Model  (FORCEM) .  However,  this  plan  also  addresses  the 
development  of  an  Engineer  Functional  Area  Model  (EFAM) . 

5.  Method .  ESC  used  the  three -step  approach  shown  in  Figure  2  to 
develop  this  plan: 

a.  Step  one.  ESC  assessed  the  current  level  of  engineer  represen¬ 
tation  in  the  fully  automated  AMIP  models.  During  its  analyses,  ESC  focused 
attention  on  three  related  aspects  of  engineer  modeling  by  asking  the  follow¬ 
ing  questions  of  each  model: 

(1)  Engineer  task  effectiveness.  Does  the  structure  of  the 
model  adequately  represent  the  effects  of  engineer  task  execution? 

(2)  Engineer  unit  effectiveness.  Does  the  model  represent 
engineer  task  execution  on  the  battlefield,  and  can  the  requirements  for,  or 
capabilities  of,  an  engineer  force  be  measured? 

(3)  Terrain  representation.  Does  the  model  use  the  quality  and 
quantity  of  digitized  terrain  data  needed  to  adequately  measure  the  influence 
of  terrain  on  the  outcome  of  the  battle? 

b.  Step  two.  ESC  established  the  desired  level  of  engineer 
representation  in  the  AMIP  models.  The  primary  criteria  used  to  develop  this 
assessment  included:  an  ESC  analysis  of  engineer  tasks,  input  from  the  Army 
modeling  community,  and  USAES  guidance. 

c.  Step  three.  Based  on  the  discrepancies  between  the  current  and 
desired  levels  of  engineer  representation,  ESC  developed  an  aggressive  model 
improvement  plan  that  addresses:  the  necessary  enhancements  to  CASTFOREM, 

VIC,  and  FORCEM;  requirements  for  an  EFAM  development;  and  digitized  terrain 
data  base  requirements  to  support  all  models. 
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EMIP  METHODOLOGY 


Figure  2 
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II.  ENGINEER  FUNCTIONS  AND  ARMY  MODELING 


6.  Introduction .  As  previously  stated,  the  purpose  of  the  EMIP  is  to 
ensure  that  engineers  are  properly  represented  in  the  Army's  combat  models. 

ESC  has  translated  this  purpose  in  a  two-fold  objective.  First,  the  models 
should  realistically  represent  the  combined  arms  conflict.  This  objective 
cannot  be  accomplished  without  a  realistic  representation  of  the  role  that 
combat  engineers  play  in  the  combined  arms  team.  Second,  the  degree  to  which 
the  engineer  functions  are  represented  in  any  particular  combined  arms  model 
should  be  commensurate  with  the  model's  intended  use  and  level  of  resolution. 
With  this  in  mind,  ESC  established  guidelines  for  the  tvp«s  of  engineer  tasks 
that  should  be  considered  in  high-,  mid-,  and  low- resolution  models,  and  used 
these  guidelines  to  evaluate  CASTFOREM,  VIC,  and  FORCEM.  In  this  section  ESC 
summarizes  that  effort,  generally  describes  the  engineer's  role  in  a  combined 
arms  environment,  and  explains  how  this  role  should  be  modeled. 

7.  Engineer  Missions.  Army  Field  Manual  (FM)  100-5,  Operations ,  gives 
the  Army's  basic  warfare  doctrine  and  describes  how  combat  engineers  con¬ 
tribute  to  the  combined  arms  team.  Engineer  missions  are  developed  in  more 
detail  in:  FM  5-100,  Engineer  Combat  Operations;  FM  5-101,  Mobility;  FM  5- 
102,  Countermobility;  FM  5-103,  Survivability;  and  FM  5-104,  General  Engineer¬ 
ing.  These  FMs  define  the  following  combat  engineer  mission  areas: 

a.  Mobility.  US  forces  conduct  mobility  tasks  to  obtain  and 
maintain  the  freedom  of  both  tactical  maneuver  and  operational  movement. 
Mobility  missions  include:  breaching  obstacles,  conducting  river  crossing 
operations,  and  preparing  and  maintaining  pioneer  trails. 

b.  Countermobility .  Countermobility  efforts  have  an  ultimate  goal 
of  delaying,  stopping,  or  channelizing  the  enemy.  Engineers  perform  counter¬ 
mobility  tasks  by  installing  linear  obstacles  (e.g.,  minefields,  antitank 
ditches)  or  point  obstacles  (e.g.,  road  craters,  bridge  demolitions). 

c.  Survivability.  The  concept  of  survivability  includes  all 
aspects  of  protecting  personnel,  weapons,  and  supplies  while  simultaneously 
deceiving  the  enemy.  Survivability  tactics  include:  constructing  fighting 
and  protective  positions  for  both  individuals  and  equipment;  and  using 
concealment,  deception,  and  camouflage. 
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d.  Sustainment  engineering.  Sustainment  engineering  primarily 
supports  the  rear  areas  which,  in  turn,  support  the  forward- deployed  force. 

It  includes  functions  such  as  maintaining  main  supply  routes,  repairing 
airfield  damage,  and  maintaining  rear  area  facilities. 

e.  Topographic  engineering.  Topographic  engineering  assists  field 
commanders  in  using  the  terrain  more  effectively.  Topographic  functional 
areas  include  terrain  analysis,  map  production  (cartography,  map  reproduction, 
and  topographic  survey),  and  map  distribution. 

8.  Engineer  Employment.  Engineer  troop  units  provide  support  through¬ 
out  the  theater  of  operations.  Combat  engineer  units  are  assigned  missions  in 
the  forward  combat  zone  (FCZ)  in  the  division  and  corps  areas.  Engineer 
combat  heavy  battalions  are  assigned  missions  in  both  the  FCZ  and  the  com¬ 
munications  zone  (COMMZ) .  Separate  engineer  companies  and  teams  are  assigned 
where  needed. 

a.  Support  in  the  division  area.  Each  US  Army  division  has  an 
organic  divisional  engineer  battalion  which  operates  as  part  of  its  combined 
arms  team.  Each  engineer  battalion's  companies  are  normally  associated  with  a 
particular  divisional  brigade  or  task  force.  These  engineer  companies  are 
normally  placed  in  direct  support  or  under  operational  control  (OPCON)  of  the 
supported  force.  Engineer  battalions  which  are  organic  to  airborne,  air 
assault,  and  light  infantry  divisions  have  fewer  resources  than  the  engineer 
battalions  in  the  other  divisions.  They  have  fewer  personnel,  less  earth 
moving  equipment,  and  no  bridging  capability.  Separate  brigades  and  armored 
cavalry  regiments  also  have  organic  engineer  companies.  An  engineer  terrain 
team  of  the  theater  topographic  engineer  battalion  normally  supports  each 
division . 

b.  Support  in  the  corps  area.  The  composition  of  engineer  units  in 
a  corps  area  depends  primarily  on  the  mission,  threat,  and  terrain  in  the 
specific  area  of  operations.  It  also  depends  on  the  availability  of  host 
nation  assets  and  the  size  of  the  supported  manuever  force.  In  general,  for  a 
five-division  corps  in  the  European  theater,  the  doctrinal  engineer  force 
might  include:  a  brigade  headquarters;  two  or  more  group  headquarters;  12 
corps  battalions;  three  heavy  battalions;  six  float  bridge  companies;  four 
medium  girder  bridge  companies;  six  combat  support  equipment  companies;  two 
dumptruck  companies;  a  cartographic  company;  five  divisional  terrain  teams;  a 


corps  terrain  team;  a  topographic  survey  platoon;  and  cellular  teams  for  real 
property  maintenance  activities,  as  required. 

c.  Support  in  the  COMMZ.  The  requirements  for  engineer  support  in 
the  COMMZ  depend  largely  on  the  character,  magnitude,  and  phasing  of  base 
development  operations.  Base  development  includes  the  initial  beddown  of 
logistics  units;  the  repair  and  renovation  of  Lines  of  Communication  (LOCs) 
and  facilities  needed  to  support  the  receipt,  storage  and  distribution  of  war 
materiel;  and  the  logistics  base  expansion  required  to  establish  a  mature 
theater.  Because  the  size  and  make-up  of  the  engineer  COMMZ  is  so  theater  and 
operation  plan  (OPLAN)  dependent,  it  is  unproductive  to  provide  a  sample  force 
sizing  for  the  COMMZ.  However,  for  a  major  theater,  the  engineer  force  would 
doctrinally  contain  an  engineer  command  headquarters  and  several  brigade 
headquarters  (each  with  two  or  more  group  headquarters).  Depending  on  the 
mission  assigned,  the  group  headquarters  would  command  and  control  a  blend  of 
combat  heavy  battalions  and  construction  support,  dump  truck,  pipeline,  port 
construction,  and  bridge  companies.  The  engineer  command  and  brigades  would 
also  control  the  numerous  topographic  units,  as  well  as  the  facility-oriented 
companies  and  teams  assigned  to  the  theater. 

d.  Support  to  other  services  and  agencies.  Army  engineers  may  also 
be  directed  to  support  other  services  and  agencies  in  the  theater  of  opera¬ 
tions.  Currently,  Army  engineers  support  the  US  Air  Force  (USAF)  by  accom¬ 
plishing  follow-on  airfield  war  damage  repair  and  restoration  to  damaged 
pavements  and  facilities,  as  well  as  all  new  construction  requirements.  Army 
engineers  also  assist  with  emergency  war  damage  repair  and  beddown  require¬ 
ments  that  exceed  Air  Force  civil  engineering  capabilities.  The  respon¬ 
sibility  to  support  the  Air  Force  is  a  major  mission  which  places  severe 
demands  on  several  Army  engineer  units  (combat  battalion  heavy,  construction 
support  equipment  companies,  and  utility  detachments)  in  a  theater  of  opera¬ 
tions  . 

9.  Engineer  Tasks.  The  above  discussion  indicates  the  diversity  of 
tasks  that  engineers  are  expected  to  perform  on  the  battlefield.  Figure  3 
groups  these  tasks  into  16  broad  task  categories  bdsed  on  the  interaction 
between  engineer  functions  and  other  combat  functions  (see  Annex  F) .  ESC  used 
these  broad  task  categories  as  a  foundation  from  which  to  develop  more 
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ENGINEER  TASK  CATEGORIES 

1.  Install  linear  obstacles  (minefields,  tank  ditches...) 

2.  Install  point  obstacles  (road  craters,  bridge  demolition...) 

3.  Prepare  fighting  positions  for  direct  fire  systems  (tanks,  TOWS...) 

4.  Prepare  positions  for  indirect  fire  &  other  systems  (artillery, 

ADA,  CP, ... ) 

5.  Breach  obstacles  in  the  assault  (breach  minefields,  span  short  gaps...) 

6.  Improve  assault  breaches  for  follow-on  forces  (clear  minefields, 

widen  lanes . . . ) 

7.  Conduct  river  crossing  operation  in  the  assault  (bank  clearing, 

rafting,  assault  bridging...) 

8.  Improve  river  crossing  site  for  follow-on  forces  (fixed  bridging, 

float  bridging . . . ) 

9.  Maintain  main  supply  routes  (fill  craters,  build  up  worn  shoulders...) 

10.  Pioneer  trail  preparation  &  maintenance  (route  clearing,  soil 

stabilization. . .) 

11.  Forward  airlanding  facility  preparation  &  maintenance  (air  strip 

clearing,  soil  stabilization...) 

12.  Site  preparation  &  maintenance  for  combat  support  &  combat  service 

support  units  (access  road,  site  clearing...) 

13.  Rear  area  facility  rehabilitation  &  maintenance  (building 

conversion,  damage  repair...) 

14.  Airfield  damage  repair  (crater  repair,  rubble  clearing...) 

13.  Port  &  waterfront  facilities  construction  &  repair  (pier  repair, 
storage  facility  rehabilitation...) 

16.  Other  (engineer  raids,  nuclear  rubble  removal...) 

Figure  3 
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specific  recommendations  about  the  modifications  which  are  needed  to  better 
represent  engineer  play  in  specific  models.  ESC  observed  that: 

a.  There  are  certain  engineer  task  categories  in  Figure  3  that  are 
outside  the  scope  of  high-resolution  models  (i.e.  CASTFOREM) .  For  example, 
the  short  engagement  times  and  the  small  battlefield  size  that  are  represented 
in  high- resolution  models  make  it  impractical  to  represent  such  tasks  as  rear 
area  facility  damage  repair  and  improving  river  crossing  sites  for  follow-on 
forces . 

b.  Most  engineer  task  categories  can  be  represented  in  mid- resolu¬ 
tion  models  (i.e.,  VIC).  Since  current  mid- resolution  models  include  the 
corps  service  areas,  they  come  closest  to  covering  all  of  the  engineer  task 
categories  identified  in  Figure  3.  Mid-resolution  models  also  have  the 
architectural  structure  to  c_commodate  the  inclusion  of  most  engineer  tasks  in 
substantial  detail. 

c.  Some  engineer  tasks  cannot  be  explicitly  represented  by  low- 
resolution  models  (i.e.,  FORCEM) .  The  design  of  current  low- resolution  models 
is  such  that  even  the  general  list  of  16  task  categories  cannot  be  explicitly 
represented  at  this  level  of  aggregation.  On  the  other  hand,  low- resolution 
models  can  address  rear  area  operations  that  cannot  be  represented  in  models 
of  other  levels  of  resolution. 


10.  Engineer  Modeling  and  CASTFOREM.  CASTFOREM  is  a  high- resolution , 
two-sided,  stochastic  simulation  of  a  small  combined  arms  conflict  lasting,  at 
most,  1-1/2  to  2  hours.  It  enjoys  general  acceptance  throughout  the  modeling 
community.  The  model  simulates  a  fire-fight  between  a  defender  of  battalion- 
size  (or  smaller)  unit  against  an  attacker  of  regimental  -  s  i -o.  (or  smaller).  A 
typical  CASTFOREM  battle  area  is  represented  by  20  x  20  kilometers  of  terrain, 
graduated  into  100  meter  grid  cells. 

a.  Background.  In  1981,  TRADOC  Analysis  Command,  White  Sands 
Missile  Range  (TRAC-WSMR)  (then  the  TRADOC  Systems  and  Analysis  Activity), 
developed  CASTFOREM  as  the  battalion- level  AMIP  model.  As  originally  con¬ 
ceived,  this  model  is  battalion  task  force  level  in  scope  and  plays  individual 
vehicles  and  weapon  systems.  Its  capacity  to  handle  complex  scenario  situa¬ 
tions  and  detailed  input  data  has  made  it  an  excellent  replacement  for 
CARMONETTE,  the  predecessor  high- resolution  model. 


b.  Engineer  modeling  considerations.  CASTFOREM  was  designed  to 
represent  the  detailed  operations  of  the  combined  arms  and  support  task  force. 
Its  primary  purpose  is  to  determine  the  effectiveness  of  units  and  individual 
systems.  As  such,  only  the  "vital"  engineer  tasks  should  be  considered  for 
representation  in  CASTFOREM.1^  These  vital  tasks  include:  preparing  fighting 
positions  (direct-fire  positions);  installing  linear  obstacles;  breaching 
obstacles  in  the  assault;  installing  point  obstacles;  preparing  fighting 
positions  ( indirect  -  fire  and  other  systems);  and  conducting  river  crossing 
operations  in  the  assault.  Unfortunately,  CASTFOREM  has  limited  ability  to 
explicitly  play  the  execution  of  these  tasks.  This  is  due  to  the  short 
duration  of  simulated  battle  (only  2  hours),  the  small  size  of  the  terrain  box 
(only  400  square  kilometers) ,  and  the  high  resolution  of  the  manuever  units 
(usually  company  size).  Nevertheless,  the  effects  of  these  tasks  are  critical 
to  CASTFOREM  realism. 

11.  Engineer  Modeling  and  VIC.  VIC  is  a  two-sided,  deterministic 
computer  simulation  of  combat  in  a  combined  arms  environment.  The  model  is 
designed  to  provide  a  balanced  representation  of  the  major  force  elements  of  a 
US  Army  corps  in  a  tactical  campaign.  The  modular  program  structure  repre¬ 
sents  friendly  air  and  land  forces  and  a  commensurate  enemy  force  in  a  mid¬ 
intensity  battle.  The  model  is  event-stepped  for  maneuver  elements  and  time- 
stepped  for  calculating  support  effects.  Maneuver  units  in  VIC  initially  move 
along  scripted  paths.  Decision  tables  exercise  command  and  control  in  the 
automated  simulation.  The  model  has  a  pre - processor  for  constructing  input 
data  files  and  comprehensive  post-processors  for  displaying  model  results. 

VIC  users  generally  represent  terrain  in  4  x  4  kilometer  grid  squares.  Three 
terrain  data  classes  (vegetation,  relief,  and  linear  obstacles  and  features) 
normally  affect  the  modeled  maneuver  units'  movement  and  visibility.  VIC  has 
been  used  by  TRAC-WSMR  and  TRADOC  Analysis  Command,  Fort  Leavenworth  (TRAC- 
FLVN)  on  six  major  studies  and  typically  simulates  three  to  six  days  of 
combat . 

a.  Background.  In  1982,  TRADOC  established  a  requirement  for  a 
corps- level  model  in  which  AirLand  Battle  Doctrine  could  be  represented  and 

^See  Annex  F  for  definitions  of  "vital,"  "critical,"  "essential,"  and 
"necessary"  engineer  tasks. 


studied.  TRAC-WSMR  decided  to  take  advantage  of,  and  improve  upon,  the  best 
features  of  existing  models  rather  than  to  develop  a  completely  new  model. 
Specifically,  VIC  was  based  on:  the  Vector-2  model’s  representation  of  ground 
combat  (developed  by  Vector  Research,  Incorporated),  and  the  USAF's  Commander 
Model's  representation  of  the  air  war  (which  evolved  from  the  Talon  Model). 

In  1985,  a  review  committee,  which  was  appointed  by  the  AMC ,  recommended  VIC 
as  the  Army's  corps/division- level  model.  In  1986,  VIC  was  adopted  into  the 
Army's  hierarchy  of  simulation  models  under  AMIP,  replacing  the  Corps/Division 
Evaluation  Model  (CORDIVEM)  simulation.  VIC  was  placed  under  configuration 
management  by  HQ  TRAC  in  April  1987. 

b.  Engineer  modeling  considerations.  According  to  AR  5-11,  VIC  is 
to  be  used  for  force  design  and  development  of  concepts,  doctrine,  and  tactics 
for  corps,  divisions,  and  brigades.  It  will  also  be  used  to  determine 
resource  requirements  for  sustained  operations  and  to  study  materiel  systems 
that  are  organic  to,  or  have  an  influence  on,  the  capabilities  of  corps, 
divisions,  or  brigades.  Because  it  is  the  Army's  mid-resolution 
corps/division  simulation  model,  VIC  should,  as  a  minimum,  represent  the 
engineer  tasks  that  are  performed  forward  of  the  corps  rear  boundary.  But, 
unlike  CASTFOREM,  which  focuses  on  the  effectiveness  of  individual  weapon 
systems,  VIC  represents  the  interactions  of  the  various  combat,  combat  support 
(CS) ,  and  combat  service  support  (CSS)  functional  areas.  Therefore,  the 
execution  of  engineer  tasks  should  be  modeled,  as  well  as  the  effects  of  those 
engineer  tasks. 

12.  Engineer  Modeling  and  the  Force  Evaluation  Model  (FORCEM) .  FORCEM 
is  a  two-sided,  time-stepped,  deterministic  theater- level  wargame .  It  plays 
both  ground  and  air  combat.  Unlike  most  other  theater  models,  FORCEM  has  a 
multi-tiered  decision  making  framework  and  includes  the  role  of  CSS  forces  at 
echelons  above  corps.  FORCEM  has  three  major  functional  areas:  situation 
development,  command  and  control,  and  an  activity  portion  consisting  of  combat 
and  support  elements.  Situation  development  builds  a  perception  base  by 
simulating  the  gathering  and  processing  of  intelligence  information,  and  the 
transmission  of  that  information  among  headquarters.  The  situation  data  is 
used  by  command  and  control  for  decision  making  at  corps,  army,  and  theater 
headquarters.  The  decision  making  process  controls  unit  and  resource 
dispositions  using  hard-wired  decision  rules  controlled  by  various  input 
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parameters.  Combat  occurs  at  several  levels:  at  the  maneuver  unit  level;  at 
the  air  war  level;  and  at  the  deep  strike  artillery  and  surface-to-surface 
missile  level.  Medical,  supply,  transportation,  maintenance,  vehicle 
recovery,  personnel,  and  engineer  functions  comprise  support  activities 
currently  modeled  in  FORCEM. 

a.  Background.  In  July  of  1981,  AR  5-11  tasked  the  US  Army 
Concepts  Analysis  Agency  (CAA)  with  the  responsibility  for  the  theater  level 
component  of  the  AMIP  hierarchy  --  the  Force  Evaluation  Model.  FORCEM 
development  began  at  CAA  in  1982,  and  the  first  working  version  was  completed 
in  1985.  It  was  used  in  a  demonstration  mode  on  the  US  Army  Operational 
Readiness  Analysis - 1985  (OMNIBUS-85)  Study.  Subsequently,  it  was  used  for 
theater  analyses  in  both  OMNIBUS-86  and  the  Combat-Support  Ratio  Study.  With 
constrained  manpower  resources  CAA  has  found,  however,  that  study  support  has 
been  at  the  expense  of  making  desired  model  refinements  and  improvements.  A 
recent  decision  has  been  made  to  push  model  development  and  forego  study 
support  for  the  remainder  of  1988. 

b.  Engineer  modeling  considerations.  CAA  designed  FORCEM  to  become 
the  Army's  principal  theater- level  wargame .  While  it  has  been  used  success¬ 
fully  on  several  studies,  FORCEM  has  not  reached  its  full  potential  as 
outlined  in  AR  5-11.  Originally,  FORCEM  was  to  support  both  capability  and 
requirements  analyses,  relying  on  the  division/corps  results  from  CORDIVEM. 

To  date,  FORCEM  has  evolved  into  a  capabilities  model  that  relies  on  division- 
level  combat  samples  from  Combat  Sample  Generator  (COSAGE) ,  and  on  Force 
Analysis  of  Theater  Administrative  and  Logistics  Support  (FASTALS)  to  round 
out  those  portions  of  the  force  which  are  not  represented  in  FORCEM  (e.g., 
engineers) .  CAA  is  constantly  improving  FORCEM  so  that  it  will  eventually 
attain  its  desired  functional  capacity.  Once  these  improvements  are  made, 
FORCEM  could  then  be  used  to  support  both  program  analyses  and  force  design. 
The  "ideal"  engineer  representation  in  FORCEM  would  simulate  all  the  tasks  in 
Figure  3.  Such  an  "ideal"  version  is,  of  course,  realistically  unattainable 
because  of  the  way  engineer  functions  are  represented.  Also,  the  level  of 
resolution  of  engineer  functions  must  be  compatible  with  the  other  functional 
components  in  the  model.  The  challenge  then  is  to  adapt  engineer 
representational  needs  with  FORCEM's  design,  components,  and  computational 


III.  CONCLUSIONS 


13.  The  Quality  of  Engineer  Modeling  Has  Not  Been  Good.  Historically , 
there  have  been  serious  deficiencies  in  the  modeling  of  engineer  functions  in 
available  force-on- force  simulations.  From  the  early  60's  to  the  late  70's, 
engineer  representation  in  the  Army's  land  combat  simulations  was  minimal,  at 
best.  The  lack  of  adequate  engineer  representation  in  the  Army's  analytical 
models  received  little,  if  any,  formal  attention  from  the  Army's  analytic 
community.  This  general  state  of  neglect  was  probably  rooted  in  the  ad  hoc 
process  that  was  commonly  used  at  the  time  to  develop  models.  Engineer- 
related  studies  were  never  high  enough  in  the  queue  to  receive  anything  but 
casual  interest  from  the  modeling  community.  Since  these  combat  models  were 
being  used  in  almost  all  Army  studies  of  combined  arms'  systems,  engineers 
were  at  a  severe  disadvantage.  Because  of  inadequate  engineer  representation 
in  these  models,  the  engineer  community  could  not  demonstrate  to  the  Army  the 
engineers'  contribution  to  combat  force  effectiveness.  Conversely,  the 
engineers  were  also  not  able  to  analyze  engineer  material  and  equipment 
requirements  within  the  context  of  a  combined  arms  simulation.  This  inade¬ 
quacy  of  combat  engineer  modeling  was  recognized  by  sources  outside  the 
engineer  community  in  a  27  February  1980  memorandum  in  which  the  Army  Chief  of 
Staff  urged  the  Chief  of  Engineers  "...to  relook  the  manner  in  which  engineers 
state  and  support  combat  engineer  systems." 

14.  The  Situation  Has  Improved.  Beginning  in  1979,  the  Army  moved 
toward  the  development  of  a  hierarchy  of  combat  and  support  models  under  AMIP. 
This  was  a  positive  step  away  from  the  ad  hoc  model  developments  that  had 
previously  thwarted  engineer  representation.  About  the  same  time,  the  USAES 
established  an  Engineer  Modeling  Program.  The  primary  goal  of  the  Engineer 
Modeling  Program  was  to  develop  an  engineer  module  for  AMIP's  corps  level 
model  (initially  called  the  Corps  Battle  Game  and  later  called  CORDIVEM) . 

Under  the  auspices  of  AMIP  and  the  Engineer  Modeling  Program,  engineer  modules 
were  developed  for  CASTFOREM,  CORDIVEM,  and  FORCEM. 

15.  Problems  Still  Exist.  Despite  recent  improvements  in  the  represen¬ 
tation  of  engineers  in  the  AMIP  models,  problems  do  still  exist.  They 

inc lude : 
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a.  The  Army  land  combat  models  do  not  adequately  demonstrate  the 
contribution  of  combat  engineers  to  the  combined  arms  battle.  ESC  believes 
that  problems  still  exist  with  the  current  engineer  representation  in  the 
following  AMIP  models: 

(1)  CASTFOREM.  The  Engineer  Module  is  in  a  state  of 
transition.  Although  CASTFOREM  currently  simulates  engineer  activities  very 
modestly,  coding  and  decision  tables  have  recently  been  added  which  will  model 
mobility  and  countermobility  tasks  explicitly.  Unfortunately,  TRAC-WSMR  has 
not  yet  published  the  results  of  the  CASTFOREM  runs  which  will  validate  the 
coding  and  decision  tables.  Once  the  changes  to  the  Engineer  Module  have  been 
accepted,  CASTFOREM  will  still  lack  the  ability  to  '-imulate  dynamic  delivery 
of  mines,  special  stand-off  mining  systems  (i.e.,  WAM)  and  obstacle 
combinations  (complex  obstacles) . 

(2)  VIC.  In  VIC,  only  engineer  units  at  the  lowest  level  can 
perform  work:  minefield  teams  (emplace  only);  linear  obstacle  teams  (emplace 
only);  bridging  teams;  and  survivability  teams  (defensive  position  construc¬ 
tion)  .  While  VIC  does  account  for  unit-allocated  equipment  and  has  the 
capability  to  attrite  specific  classes  of  equipment,  the  availability  and 
capability  of  that  equipment  does  not  affect  the  rate  at  which  engineer  units 
accomplish  their  tasks. 

(3)  FORCEM.  To  find  engineer  play,  one  must  look  to  models 
that  support  FORCEM:  COSAGE  produces  the  samples  used  for  combat  results 
calculations;  and  FASTALS  determines  engineer  unit  resource  requirements  for 
COMMZ  tasks  through  the  force  round-out  process.  After  looking  at  engineer 
play  or  treatment  across  all  three  models,  ESC  found  the  following: 

(a)  COSAGE  considers  only  one  engineer-related  activity  -- 
the  breaching  of  pre-emplaced  minefields.  The  method  used  to  extrapolate 
results  from  combat  samples,  as  well  as  the  samples  themselves,  appears  to 
ignore  the  role  of  engineer  forces.  Thus  the  important  role  of  divisional  and 
corps  engineers  on  the  battlefield  is  ignored. 

(b)  Although  FASTALS  does  consider  some  engineer  tasks,  it 
does  not  include  several  "vital"  tasks  that  have  important  resource  and  force 
effectiveness  implications.  Task  estimates  appear  to  use  workload  parameters 
that  are  both  overly  general  and  subjective.  More  importantly,  since  it  is  a 


requirements  model,  FASTALS  cannot  indicate  what  effect  engineers  have  on  the 
conduct  of  the  war. 

(c)  FORCEM  also  fails  to  consider  such  tasks  as  US  Army 
engineer  assistance  to  USAF  engineers  when  airbase  damage  or  beddown 
requirements  exceed  USAF  capability.  Even  if  VIC  replaces  COSAGE  as  the 
combat  sample  generator,  the  engineer  work  which  occurs  in  the  corps  rear  (the 
gap  between  COMMZ  and  FCZ)  will  have  to  be  addressed. 

b.  Engineer- sponsored  studies  are  typically  not  high  on  the  TRADOC 
list  of  priority  studies.  Even  though  historically  the  combat  engineer  has 
been  an  indispensable  member  of  the  combined  arms  team,  studies  to  support  the 
modernization  of  the  engineer  force  cannot  successfully  compete  for  scarce 
TRAC  modeling  resources.  The  consequences  of  this  low  priority  for  engineer 
studies  is  twofold.  First,  since  most  of  the  enhancements  to  production 
models  (i.e.  CASTFOREM,  VIC,  and  FORCEM)  are  study-driven,  engineer  represen¬ 
tation  in  these  models  does  not  evolve  as  rapidly  as  does  the  representation 
of  other  higher  priority  functional  areas.  (The  top  priority  at  TRAC  is  study 
support  --  not  model  research  and  development.)  Second,  the  USAES  must  look 
elsewhere  for  modeling  support.  The  USAES  has  access  to  several  non-AMIP 
models,  but  none  that  are  both  adequate  to  address  engineer-specific  questions 
and  provide  credible  results  in  the  eyes  of  the  Army's  analytical  community. 
The  engineer  study  program  suffers  on  both  counts. 

c.  The  availability  of  digital  terrain  data  (DTD)  is  not  adequate 
to  support  the  Army's  analytic  community.  Identification  and  production  of 
DTD  to  support  the  Army's  analytic  community  has  been  inadequate.  Most  DTD 
coverage  for  the  Army's  OPLANs  is  for  locations  supporting  TRADOC -approved 
scenarios  in  the  Federal  Republic  of  Germany  (FRG) .  As  a  result,  CAA  cannot 
conduct  simulations  which  adequately  represent  terrain  (and  therefore  engineer 
functions)  in  their  other  theater- level  studies.  DTD  inadequacies  also 
preclude  agencies  such  as  ESC  and  Army  Materiel  Systems  Analysis  Agency 
(AMSAA)  from  adequately  representing  terrain  in  their  VIC  or  CASTFOREM 
simulations  of  combat  in  world  areas  other  than  the  FRG. 
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IV.  RECOMMENDATIONS 


16.  Only  a  Few  Changes  Are  Needed  in  CASTFOREM.  For  engineer  unit  and 
force  structure  studies,  CASTFOREM's  applicability  is  limited.  It  cannot  be 
expected  to  realistically  model  the  engineer's  flexible  and  responsive  support 
structure.  It  is,  however,  an  invaluable  tool  for  evaluating  the  effects  of 
specific  engineer  tasks  (e.g.,  emplacing  obstacles)  or  the  operational 
effectiveness  of  individual  engineer  systems.  With  the  recent  improvement  of 
the  Engineer  Module,  USAES  and  TRAC-WSMR  have  made  substantial  progress  toward 
adequately  representing  engineers  in  CASTFOREM.  The  first  priority  will  be 
for  USAES  and  TRAC-WSMR  to  publish  the  results  of  the  validation  of  the 
mobility  and  countermobility  coding  and  decision  tables.  A  few  additional 
changes  are  recommended  at  this  time  to  improve  the  realism  of  CASTFOREM's 
combined  arms  representation.  Those  improvements  are  discussed  in  detail  in 
Annex  A. 


1 7 .  VIC  Requires  an  Expansion  in  the  Number  of  Engineer  Tasks  and 
Effects  That  Are.  Currently  Represented.  VIC  was  designed  to  represent  the 
interactions  of  the  various  combat,  CS ,  and  CSS  functional  areas.  As  an 
analytical  tool,  its  purpose  is  to  support  design  and  structure  tradeoff 
analyses  of  Army  organizations  such  as  brigade,  division  and  corps.  (VIC  can 
also  support  studies  of  certain  item  systems  organic  to  major  organizations.) 
It  is  for  these  reasons  that  VIC  must  provide  a  reasonable  and  balanced 
representation  of  each  functional  area,  and  accurately  portray  the  contribu¬ 
tion  of  each  functional  area  to  the  combined  arms  conflict.  Currently,  VIC 
represents  a  few  engineer  tasks  and  effects  well.  However,  many  tasks  and 
effects  are  represented  poorly  or  not  at  all.  To  maintain  a  reasonable  and 
balanced  representation  in  VIC,  engineer  units  should  continue  to  be  modeled 
explicitly.  However,  the  representation  of  engineer  unit  capability  under  a 
more  flexible  modeling  arrangement  could  improve  the  realism  of  the  current 
tasks  played  in  the  model  and  permit  the  inclusion  of  additional  engineer 
tasks.  Annex  B  of  this  report  identifies  37  improvements  that  ESC  recommends 
be  made  to  the  engineer  representation  in  VIC. 


18 .  Adequate  Engineer  Representation  in  FORCF.M  Will  Require  a  New 
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was  designed  to  become  the  Army’s  principal  theater - leve 1  wargame.  Looking  to 


that  time,  FORCEM  will  have  to  be  improved  if  it  is  to  fairly  represent 
engineer  activities  in  the  theater  well  enough  to  evaluate  capabilities  and 
calculate  requirements.  Moreover,  the  improvements  are  interrelated; 
accomplishing  one  without  making  progress  in  others  will  gain  nothing.  Unless 
terrain  and  installations  are  satisfactorily  represented,  the  effects  they 
have  on  various  modeled  units  and  processes  cannot  be  calculated.  Nor  can 
engineer  tasks  have  any  reasonable  basis  without  adequately  representing  the 
object  on  which  they  work.  Annex  C  of  this  report  identifies  the  specific 
improvements  ESC  recommends  for  FORCEM. 

19.  The  Engineer  Community  Needs  a  Functional  Area  Model.  Each 
proposal  for  improving  the  Army's  equipment,  organization,  or  training  must  be 
analyzed  in  detail  to  demonstrate  the  cost  and  operational  effectiveness  of 
the  proposed  change.  Those  organizations  or  systems  with  the  greatest 
perceived  pay-off  are  normally  chosen  for  acquisition.  Combat  engineer 
systems,  lacking  the  support  of  robust  analytical  techniques,  often  do  not 
make  the  initial  cut.  There  are  several  reasons  for  this.  First,  the  Army 
land  combat  models  do  not  adequately  demonstrate  the  contribution  of  engineer 
systems  to  the  combined  arms  battle,  much  less  have  the  breadth  and  depth  to 
address  specific  engineer  issues .  Second,  even  if  they  did,  engineer- spon¬ 
sored  studies  are  typically  not  high  on  the  TRADOC  list  of  priority  studies. 
Therefore,  they  are  often  performed  without  modeling  support  from  TRAC,  using 
models  that  do  not  have  the  credibility  that  AMIP  models  enjoy.  A  develop¬ 
mental  program  should  be  undertaken  with  the  ultimate  goal  of  providing  USAES 
with  an  appropriate,  analytically  acceptable,  and  Army  approved  corps/div¬ 
ision-level  model.  Annex  D  to  this  report  presents  the  requirements  specifi¬ 
cations  for  an  EFAM.  Generally,  the  model  should  be  stand-alone,  but 
logically  linked  to  VIC.  It  must  be  capable  of  addressing  the  following  types 
of  analyses; 

a.  Engineer  force  structure  or  design  questions. 

b.  Engineer  logistics  questions. 

c.  Contribution  of  engineers  to  the  combined  arms  conflict. 

20.  The  Army  Needs  More  Extensive  Area  Coverage  For  DTD.  ETL  included 
the  needs  of  the  Army  analysis  community  in  their  1989  study,  Army  Digital 
Topograph ic  Data  Requirements .  These  requirements  were  validated  by  0DCS1NT 
and  were  formally  presented  to  the  Defense  Mapping  Agency  (DMA)  in  October 
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1984.  However,  as  discussed  in  Annex  E,  DMA  does  not  plan  to  begin  producing 
data  to  meet  these  requirements  until  some  time  after  1992.  The  Army  must, 
therefore,  establish  its  most  critical  DTD  needs  (those  that  cannot  wait  for 
the  new  DMA  system)  and  develop  a  cost  effective  method  of  producing  this 
urgently  needed  data.  To  avoid  needless  duplication  of  effort,  the  Engineer 
Topographic  Laboratories  (ETL)  must  establish  standards  and  specifications  for 
the  Army's  interim  terrain  product  needs  and  require  that  all  new  production 
efforts  follow  these  standards.  Annex  E  to  this  report  discusses  the  current 
DTD  deficiencies  in  detail,  proposes  an  organization  that  should  be  charged 
with  correcting  these  deficiencies,  and  estimates  the  professional  staff  years 
of  effort  (and  dollar  cost)  that  must  be  committed  to  solve  the  problem. 

21 .  Off-line  Analysis  Addressing  Eneineer  Task  Effectiveness  Will  Be 
Required  to  Support  Model  Development.  Before  an  engineer  task  can  be 
successfully  integrated  into  an  AMIP  model  (including  EFAM) ,  supporting  data 
will  have  to  be  developed.  ESC  recommends  that  each  engineer  ta^k  (see  Annex 
F)  be  researched  and  analyzed  using:  historical  data;  results  of  field 
tests/exercises;  and  surveys  of  opinions  from  subject  matter  experts. 
Deficiencies  in  the  available  data  necessary  to  support  the  modeling  of 
engineer  task  effects  should  be  identified  and  appropriate  remedial  actions 
taken.  This  is  the  area  in  which  ESC  intends  to  commit  substantial  effort 
during  the  next  several  years. 


V.  IMPLEMENTATION 


22.  EMIP  Tasks .  To  effectively  implement  the  recommendations  cited  in 
Section  IV,  ESC  has  established  four  separate  programs:  a  CASTFOREM  program, 
a  combined  EFAM-VIC  program,  a  FORCEM  program,  and  a  DTD  development  program. 
ESC  will  manage  the  first  three  programs;  ETL  will  manage  the  fourth  program. 
The  EFAM-VIC  program  will  serve  as  the  centerpiece  for  engineer  modeling 
research  and  development  and  provide  improved  methodologies  and  data 
representations  that  can  be  exported  to  the  CASTFOREM  and  FORCEM  programs  when 
appropriate.  These  three  programs  will  be  managed  by  a  three-person  ESC  cell 
that  has  combat  engineer  modeling  as  its  singular  mission.  Since  the  Army's 
need  for  interim  DTD  production  encompasses  a  great  deal  more  than  just  the 
modeling  community,  ESC  has  established  a  separate  DTD  production  program. 

This  program  should  be  funded  separately  from  the  EMIP  and  managed  by  the 
Engineer  Topographic  Laboratories. 

a.  The  CASTFOREM  program.  The  desired  engineer  representation  in 
CASTFOREM  will  be  developed  in  two  phases. 

(1)  Phase  one.  This  is  a  continuation  of  a  USAES  effort  which 
was  initiated  with  TRAC-WSMR  in  May  1987  to  measure  the  combat  power  of 
minefields.  This  study  will  result  in  an  effective  Engineer  Module  in 
CASTFOREM  und,  perhaps  more  important,  will  lead  to  a  general  recognition  and 
acceptance  by  TRADOC  users  of  the  value  of  engineer  representation  to  the 
overall  model's  effectiveness.  This  phase  includes  the  addition  of  engineer 
activities  associated  with  mines,  antitank  ditches,  short  gaps,  and  road 
craters.  Although  TRAC-WSMR  has  validated  the  new  code  and  decision  tati.es, 
it  has  yet  to  publish  the  results. 

(2)  Phase  two.  This  phase  would  start  after  the  completion  of 
the  first  phase  and  would  add  WAM ,  dynamic  delivery  of  mines  by  artillery  or 
air,  and  obstacle  combinations. 

b.  The  EFAM-VIC  program.  This  is  by  far  the  biggest  EMIP  effort 
and  will  provide  the  greatest  pay-off  in  terms  of  support  lor  engineer 
analyses.  After  independently  analyzing  the  desired  engineer  representation 
in  VIC  (see  Annex  B)  and  the  requirements  specifications  for  an  EFAM  (see 
Annex  D) ,  ESC  found  that  the  two  model  improvement  efforts  have  a  lot  in 

More  precisely,  if  the  engineer  representation  in  VIC  is  enhanced 


common . 


(per  ESC's  recommendations),  the  development  program  of  an  EFAM  (using  VIC  as 
a  basis)  would  be  about  70  percent  complete.  Therefore,  ESC  has  chosen  to 
merge  the  two  efforts  into  a  single  program  as  shown  in  Figure  4.  All 
modifications  to  VIC  will  be  implemented  on  a  USACE  R&D  version  of  VIC  before 
being  offered  to  TRAC's  reference  version  of  VIC,  the  EFAM,  or  both.  EFAM-VIC 
activities  will  be  programmed  as  follows: 

(1)  VIC  phase  one.  This  phase  initiates  14  improvements  to 
VIC.  The  major  thrust  of  this  phase  is  to  revise  the  method  of  representing 
engineer  units  and  their  capability  in  VIC.  These  improvements  include  not 
only  the  method  of  representation  of  engineer  units,  but  also  resource 
allocation  and  constraints,  attrition,  and  effects  of  degradations  on  task 
performance.  Accomplishing  these  improvements  will  provide  a  more  flexible 
and  realistic  representation  of  engineer  units  and  provide  the  framework  for 
adding  additional  engineer  tasks.  Additionally,  this  phase  starts  the 
programming  effort  for  many  of  the  recommended  countermobility,  mobility,  and 
survivability  improvements  in  VIC.  Finally,  this  phase  also  initiates  the 
effort  to  coordinate  changes  to  the  "coordinated  group  move"  logic,  and  adds 
the  capability  for  air-delivered  mines,  maneuver  units  to  use  roads,  and 
forward  aviation  engineer  tasks. 

(2)  VIC  phase  two.  The  phase  two  work  will  complete  VIC 
engineer  representation  in  two  areas.  First,  the  foundation  that  began  in 
phase  one  for  incorporating  a  host  of  engineer  tasks  will  provide  a  more 
complete  set  of  engineer  task  effects  for  gaming  in  VIC.  Second,  a  series  of 
post-processor  reports  will  be  implemented  to  extract  engineer  task  data  from 
VIC  that  could  be  used  for  more  detailed  engineer  analysis. 

(3)  VIC  phase  three.  The  phase  three  work  will  focus  on  the 
design  and  implementation  of  an  internal  decision  process  using  the  command 
and  control  structure  and  an  analysis  of  the  situation  to  generate  new 
engineer  jobs.  With  this  structure  in  place,  those  engineer  tasks  which  arise 
from  the  situation  and  are  not  a  part  of  the  input  data  will  be  fully 
implemented . 

(4)  VIC  phase  four.  The  phase  four  work  will  complete  the 
representation  of  engineer  tasks  by  adding  those  tasks  which  are  dependent  on 
the  implementation  of  roads  or  which  involve  coordination  outside  of  the 
engineer  community. 
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(5)  EFAM  additions.  This  phase  will  complete  the  representa¬ 
tion  of  engineer  tasks  that  are  required  in  the  EFAM,  but  not  necessarily 
desirable  for  VIC.  Predominant  in  this  category  are  sustainment  engineering 
tasks.  In  addition,  the  VIC  structure  will  be  modified  to  accommodate 
operation  of  the  model  in  a  requirements  mode  and  additional  post-processor 
reports . 

(6)  EFAM  fielding.  This  phase  consists  of  all  the  activities 
necessary  to  test,  modify,  and  field  a  final  version  of  the  EFAM. 

(7)  Support  activities.  The  following  support  activities  will 
be  performed  concurrently  with  the  above  six  phases: 

(a)  Data  research.  Tactical  decision  rules  for  executing 
engineer  tasks  will  be  defined,  and  data  sets  to  support  engineer  modeling 
will  be  developed.  The  identification,  collection,  and  validation  of  engi¬ 
neer-related  data  resulting  from  this  research  effort  will  also  support  model 
improvement  efforts  in  CASTFOREM  and  FORCEM. 

(b)  Unit  movement  research.  This  activity  will  consist  of 
basic  research  into  the  representation  of  unit  movement  in  the  VIC  model. 
Deliverable  products  resulting  from  this  research  will  include:  changes  to 
the  "coordinated  group  move"  logic;  adding  the  capability  for  maneuver  units 
to  use  roads;  and  improvements  in  terrain  representation. 

(c)  R&D  VIC  maintenance.  As  previously  mentioned,  a 
single  R&D  version  of  VIC  will  be  maintained  by  USACE.  As  the  code  is 
developed  in  support  of  the  EFAM-VIC  program,  it  will  be  implemented  and 
tested  on  the  USACE  R&D  VIC.  This  version  of  VIC  will  be  fully  operational 
and  capable  of  serving  as  a  prototype  for  EFAM. 

c.  The  FORCEM  program.  To  adequately  represent  the  contribution  of 
engineers  in  FORCEM  requires  a  three-phase  approach: 

(1)  Phase  one.  FORCEM  would  be  modified  to  use  division- level 
combat  data  from  the  planned  engineer  enhanced  VIC. 

(2)  Phase  two.  Improvements  would  be  made  to  FORCEM 's  repre¬ 
sentation  of  terrain,  installations,  and  un; ts . 

(3)  Phase  three.  Identified  engineer  tasks  (see  Annex  C)  and 
effects  would  be  incorporated  in  FORCEM. 

d.  The  DTD  program.  ETL  should  manage  the  production  of  interim 
DTD  production  by  allocating  the  available  resources  in  the  order  of  priority 
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established  by  the  ODCSINT  and  ODCSOPS .  ESC's  recommended  priority  order 
(based  only  on  model  requirements,  not  the  more  important  tactical  and  C^I 
systems  requirements)  is  given  in  Annex  E.  A  program  schedule  and  resource 
requirements  based  on  ESC's  recommendations  are  also  outlined  in  Annex  E. 

Based  on  the  Army-wide  importance  of  DTD  to  support  systems  in  the  field,  this 
program  should  be  considered  separate  from  EMIP. 

23.  EMIP  Schedule.  ESC  believes  that  EMIP  must  be  aggressively  pursued 
and  completed  in  a  timely  manner.  Extending  the  program  over  an  indefinite 
period  of  time  would  be  wasteful.  The  Army's  efforts  to  modernize  the  total 
force  have  been  and  will  continue  to  be  expensive.  Decisions  concerning 
procurement  must  focus  on  systems  that  can  demonstrate  a  high  urgency  of  need 
and  pay-off.  The  longer  the  engineer  community  delays  in  producing  convincing 
engineer  system  requirements  statements,  the  more  likely  they  are  of  falling 
even  further  behind  the  rest  of  the  Army.  The  same  argument  can  be  made  for 
defending  the  engineer  force  in  the  Army  force  structuring  process.  There¬ 
fore,  ESC  has  scheduled  all  EMIP  activities  to  be  completed  within  the  next 
three  fiscal  years.  Figure  5  shows  the  EMIP  schedule  subdivided  by  activity. 

24.  Resourcing  EMIP.  ESC  estimates  that  the  EMIP  program  shown  in 
Figure  5  will  require  27.5  professional  staff  years  of  effort,  at  a  funding 
level  of  approximately  $3,j«5K.“’  ESC  has  recommended  a  lead  agency  for  each 
EMIP  activity,  in  light  of  their  areas  of  responsibility,  experience,  and 
capabilities.  Any  of  these  lead  agencies  may  choose  to  seek  contractor 
support.  Recommended  agency  responsibilities  are  shown  in  Figure  6.  Figures 
7  and  8  summarize  the  EMIP  resource  requirements  by  organization  and  program, 
and  by  organization  and  year,  respectively.  For  programming  purposes,  ESC  is 
requesting  that  AMSAA,  TRAC,  CAA ,  and  USAES  provide  a  total  of  8  professional 
staff  years  of  effort  on  a  non- reimbursable  basis.  USACE  (CERL,  ESC,  and  WES) 
will  provide  19.5  professional  staff  years  of  effort  on  a  cost  sharing  basis 
(approximately  70  percent  USACE  funded  and  30  percent  AMIP/USAES  funded) . 

^Based  mostly  on  cost  estimates  obtained  from  WES  and  CERL.  When  data  was 
not  available,  ESC  used  a  cost  estimating  relationship  of  $10,000  per 
professional  staff  month  of  effort.  This  estimate  includes  approximately 
$7,500  for  personnel  costs,  $1,000  for  travel,  and  $1,500  for  other  expenses 
(e.g.,  computer  time,  contractor  support). 
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RECOMMENDED  AGENCY  RESPONSIBILITY 


FY  89 


FY  90 


FY  91 


FY  92 


-  Phase  I 

-  Phase  II 


-  VIC  Phase  I 

-  VIC  Phase  II 

-  VIC  Phase  III 

-  VIC  Phase  IV 

-  EFAM  Additions 

-  Data  Research 

-  Unit  Movement  Research 

-  R&D  VIC  Maintenance 

-  EFAM  Fielding 

FQRCEM 

-  Phase  I 

-  Phase  II 

-  Phase  III 
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PROFESSIONAL  STAFF  YEAR 
ESTIMATES  by  MODEL 


AGENCY 

CASTFOREM 

EFAM-VIC 

FORCEM 

TOTAL 

TRAC 

0.5 

1.0 

- 

1.5 

AMSAA 

- 

0.5 

- 

■a 

CAA 

- 

- 

mm 

3.0 

USAES 

0.5 

mm 

0.5 

3.0 

USACE 

0.5 

16.0 

■sa 

19.5 

TOTAL 

1.5 

19.5 

6.5 

27.5 

Figure  7 


PROFESSIONAL  STAFF  YEAR 
ESTIMATES  by  FY 


AGENCY 


TRAC 


AMSAA 


CAA 


USAES 


USACE 


TOTAL 


FY89 


0.75 


0.25 


1.00 


7.75 


9.75 


FY90 


0.75 


0.25 


3.00 


1.00 


7.25 


12.25 


FY91 


1.00 


4.50 


5.50 


TOTAL 


1.50 


0.50 


3.00 


3.00 


19.5 


27.5 


Figure  8 


25.  Making  EMIP  Work.  The  EMIP  is  not  a  rigid  program  to  be  either 
implemented  blindly  or  with  rose-colored  glasses.  Rather,  it  is  a  strategy 
that  is  designed  to  guide  engineer  modeling  improvements  over  the  next  few 
years.  It  is  an  engineer  community  plan,  developed  by  ESC  in  conjunction  with 
USAES ,  and  supported  by  USACE.  What  we  can  learn  from  our  past  efforts  in 
combat  engineer  modeling  is  that  the  engineer  and  the  modeling  communities 
must  share  objectives  and  be  willing  to  work  together  as  a  team.  Otherwise, 
the  EMIP  cannot  be  an  effective  program. 

a.  EMIP  update.  Beyond  the  first  year,  professional  staff  year  and 
cost  estimates  for  the  EMIP  are  simply  planning  figures  --  they  must  be 
continuously  reviewed  and  revised.  In  addition,  ESC  developed  this  plan  as  a 
near-term  fix  to  the  most  critical  problems  (i.e.,  the  automated  AMIP  models). 
Once  EMIP  is  underway  (i.e.,  no  later  than  FY90) ,  ESC  will  refocus  its 
attention  to:  the  interactive  analytical  and  training  simulations;  and  the 
next  generation  of  AMIP  models  (e.g.,  Conflict  Model  [CONMOD]).  Future 
revisions  of  the  EMIP  plan  will  reflect  these  and  other  efforts. 

b.  AMIP  support.  EMIP  has  been  designed  to  enrich  the  combat 
realism  of  the  AMIP  models.  It  is  not  intended  to  overburden  any  model  with 
unnecessary  detail.  As  such,  ESC  has  carefully  considered  the  impact  of  its 
recommendations  on  each  specific  model  and  feels  that  the  recommended  changes 
are  appropriate  and  desirable  to  the  Army  community  as  a  whole;  not  just  the 
engineer  community.  USACE  is  willing  to  commit  resources  to  EMIP,  but  USACE 
support  alone  is  not  enough.  The  AMIP  community  (i.e.,  AMMO,  TRAC,  CAA, 

AMSAA,  USAES)  has  to  feel  that  EMIP  is  worthwhile,  and  be  willing  to  provide 
substantial  support.  Figure  9  shows  the  EMIP  funding  requirements  for  this 
comprehensive  improvement  program,  and  Figure  10  indicates  the  programmed  and 
unprogrammed  funding  sources.  ESC  believes  that  full  support  of  and 
implementation  of  the  EMIP  Plan  is  appropriate  and  clearly  in  the  best 
interest  of  the  US  Army. 
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EMIP  FUNDING  REQUIREMENTS  ($K) 


AGENCY 

FY89 

FY90 

FY91 

TOTAL 

CERL 

270 

240 

145 

655 

WES 

595 

505 

410 

1,510 

ESC 

190 

250 

220 

660 

DATA 

240 

320 

560 

TOTAL 

1,295 

1,315 

775 

3,385 

Figure  9 


EMIP  FUNDING  SOURCES  ($K) 


FUNDING  SOURCE 

FY89 

FY90 

FY91 

TOTAL 

PROGRAMMED 

(USACE) 

755 

740 

630 

2,125 

UNPROGRAMMED 

(AMIP  /  FAM-D) 

440 

45 

960 

(USAES) 

100 

• 

100 

300 

TOTAL 

1,295 

1,315 

775 

3,385 

Figure  10 
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I .  INTRODUCTION 


1.  Purpose ,  This  annex  evaluates  how  effectively  and  appropriately 
combat  engineers  are  represented  in  the  Combined  Arms  and  Support  Task  Force 
Evaluation  Model  (CASTFOREM) ,  and  suggests  how  the  model's  coverage  of 
engineer  activities  can  be  enhanced. 

2.  Scope .  This  analysis: 

a.  Presents  an  overview  of  the  CASTFOREM  environment  and  battle¬ 
field  simulation. 

b.  Examines  the  specific  play  of  engineer  units  within  the  overall 

model . 

c.  Provides  a  measure  of  the  quality  of  current  engineer  represen¬ 
tation. 


d.  Provides  some  enhancements  or  modifications  which  should  be 
addressed  during  future  program  development. 

3.  Limits .  This  annex  is  not  offered  as  a  users  manual  nor  as  the 
definitive  source  of  information  about  CASTFOREM's  military  and  modeling 
logic.  Persons  interested  in  a  more  in-depth  presentation  of  the  model's 
characteristics  should  consult  the  CASTFOREM  documentation  published  by  the 
Training  and  Doctrine  Analysis  Command  at  White  Sands  Missile  Range  (TRAC- 
USMR) ,  New  Mexico. ^  The  five  volumes  include:  an  overview  of  the  CASTFOREM 
modeling  logic;  the  interrelationships  among  the  model's  data  files  during  the 
model  runs;  and  an  outline  of  the  data  variables  and  the  structure  of  each  of 
the  data  files. 

a.  This  analysis  examines  the  quality  and  enhancement  of  modeling 
logic  within  the  CASTFOREM  environment  which  treats  combat  engineer  and 
engineer- like  activities.  Engineer- like  activities  are  those  that  involve 
traditional  engineer  battlefield  systems,  but  may  not  require  the  direct  sup¬ 
port  of  equipment  and  personnel  from  engineer  combat  support  units.  Examples 
of  equipment  used  in  engineer- like  activities  are  aircraft-  and  artillery- 
delivered  mines  and  tank-mounted  counter-mine  rollers  and  plows. 


^In  five  volumes,  CASTFOREM:  Executive  Summary;  CASTFOREM :  User  Input 
Guide;  CASTFOREM :  Scenario  Writers  Guide;  CASTFOREM :  Post- processor  Guide; 
CASTFOREM :  Methodologies  (TRAC-WSMR,  February  1988) . 
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b.  The  ability  of  CASTFOREM  to  effectively  model  non-engineer 
systems,  tactics,  C  ,  and  vehicle  maneuvers  is  examined  only  as  these  issues 
affect  combat  engineer  activities. 

4.  Background .  CASTFOREM  is  a  versatile,  robust,  high-resolution,  two- 
sided,  force-on- force ,  stochastic,  systemic  simulation  model  of  a  combined 
arms  conflict.  It  enjoys  universal  acceptance  within  the  modeling  and  TRADOC 
communities.  The  model  simulates  a  fire-fight  battle  between  a  defender  of 
battalion-size  or  smaller  against  an  attacker  of  regimental - size  or  smaller. 
Whereas  low-resolution  models  sv.'-h  as  FORCEM  simulate  a  conflict  across  an 
entire  theater  (600  by  600  kilometers)  that  may  last  up  to  180  days  and 
beyond,  CASTFOREM  simulates  much  smaller  conflicts  lasting,  at  most,  1-1/2  to 
2  hours.  The  normal  CASTFOREM  battle  area  currently  being  played  measures  20 
kilometers  by  20  kilometers  and  is  graduated  into  100-meter  terrain  cells. 

a.  The  model  keeps  detailed  records  of  terrain  features,  individual 
vehicles,  and  weapons  systems.  CASTFOREM  can  even  be  configured  to  simulate 
the  actions  of  individual  soldiers.  The  model  keeps  an  accounting  of  avail¬ 
able  and  used  projectiles,  and  of  the  flight  characteristics  and  kill  proba¬ 
bilities  of  each. 

b.  Because  CASTFOREM  is  a  stochastic  model,  several  model  runs  of 
the  same  study  scenario  are  required  to  eliminate  aberrant  combat  results. 
Typically,  TRAC-WSMR  runs  the  model  12  to  20  times  for  each  alternative 
situation  postulated  by  a  study.  On  a  VAX  8800,  the  ratio  of  computer  time  to 
simulated  battle  time  is  approximately  2  to  1 .  The  typical  battle  simulation 
lasts  no  more  than  2  hours,  resulting  in  a  computer  run  of  4  hours  per 
iteration. 

c.  CASTFOREM  can  currently  simulate  many  engineer  activities. 
Acquisition  probabilities  are  degraded  if  target  vehicles  occupy  protective 
fighting  positions.  The  amount  of  degradation  depends  on  whether  the  vehicle 
is  in  hull  or  turret  defilade.  Obstacles  can  be  played  explicitly.  The 
location  of  mines  within  minefields  and  their  effects  against  target  vehicles 


^Interview  between  ESC  and  Mr.  A.  Freeberg  (Engineer  Cell,  TRAC-WSMR, 
*  2  March  1988 ) . 
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which  attempt  to  force  the  minefield  are  modeled  in  detail.  CASTFOREM  also 
models  the  effect  of  breaching  minefields  and  other  obstacles.-^ 

d.  CASTFOREM  was  developed  by  the  TRAC-WSMR  in  1981.  TRAC-WSMR 
maintains  an  official  version  of  CASTFOREM,  which  they  call  the  "floor"  model. 
Because  this  version  enjoys  the  approval  of  the  Army  modeling  community,  it  is 
the  only  version  used  to  support  study  requests  that  demand  high-resolution 
modeling  techniques. 

e.  CASTFOREM  is  used  by  the  TRADOC  community  to  evaluate,  under 
wartime  conditions,  the  combat  characteristics  of  developmental  hardware  items 
for  the  Army.  It  is  used  to  examine  the  effectiveness  of  specific  tactical 
maneuvers  against  enemy  weapons  arrays.  With  CASTFOREM,  it  is  possible  to 
measure  the  battlefield  contribution  of  such  items  as  armored  vehicles,  wea¬ 
pons,  and  helicopters.  It  is  also  possible  to  evaluate  emerging  or  current 
tactics  and  doctrine.  Cost  and  Operational  Effectiveness  Analyses  (COEAs) 
required  by  HQDA  and  HQ  TRADOC  for  new  equipment  are  supported  by  data  derived 
from  CASTFOREM.  CASTFOREM  is  used  to  evaluate  the  operational  effectiveness 
of  integrated  systems  in  the  combined  arms  environment  and  to  determine  an 
optimum  quantity  and  mix  of  system  components  in  tactical  combat  organiza¬ 
tions.  CASTFOREM  data  are  used  to  develop  input  data  and  decision  tables  for 
the  Army's  mid-resolution  model,  Vector- in-Commander  (VIC),  and  low- resolution 
model,  FORCEM. 

f.  TRAC-WSMR  is  the  proponent  for  CASTFOREM  and  is  responsible  for 
CASTFOREM  configuration  control.  The  CASTFOREM  program  is  written  in 
SIMSCRIPT  II. 5.  In  addition  to  the  floor  version,  TRAC-WSMR  maintains  a 
separate  research  and  development  (R&D)  version  of  CASTFOREM.  Agencies  can 
request  that  the  TRAC-WSMR  staff  add  to  or  change  the  modeling  logic  of  the 
R&D  version  to  respond  to  a  specific  study  question  that  cannot  be  answered 
using  the  floor  version.  They  can  also  use  the  R&D  version  to  test  or 
validate  newly  developed  code  before  recommending  that  they  be  included  in  the 
floor  model.  However,  any  changes  to  the  floor  model  must  have  the  approval 
of  the  TRADOC  community. 


O 

-‘TRAC-WSMR  recently  revised  the  obstacle  encounter  section.  The  USAES  is 
currently  validating  the  decision  tables  which  support  this  section  through  a 
1988  countermobility  study.  (Also  see  paragraph  4h . ) 
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g.  In  1983,  the  TRADOC  users  began  an  extensive  R&D  effort  designed 
to  enhance  the  existing  wargaming  capabilities  of  the  CASTFOREM.  The  US  Army 
Engineer  School  (USAES)  officially  joined  this  effort  in  1984  under  the 
auspices  of  the  CASTFOREM  Engineer  Modeling  Feasibility  Study.  This  R&D  study 
tasked  TRAC-WSMR  ro  develop  rhe  code  necessary  to  realistically  portray 
batciefield  obstacle  and  counter-obstacle  activities.  During  the  ensuing  two 
to  three  years,  the  staff  at  TRAC-WSMR  progressed  from  an  R&D  effort  to  an 
Army  study  support  effort.  TRAC-WSMR' s  transition  to  study  support  occurred 
as  the  enhanced  version  of  the  CASTFOREM  gained  acceptance  ’Jithin  the  TRADOC 
and  modeling  communities.  Work  on  R&D  efforts  ceased  as  TRAC-WSMR  assets  were 
diverted  to  support  the  higher  priority  Army  studies. 

h.  Representatives  of  the  USAES  say  that  because  of  higher  study 
priorities  at  the  TRAC-WSMR  during  past  years,  the  school  had  been  unable  to 
obtain  CASTFOREM  staff  support  from  TRAu-WSMR  for  the  engineer  obstacle/ 
counter-obstacle  R&D  effort.  Higher  priority  studies  from  the  combat  arms 
study  community  had  filled  the  queue  to  capacity.  The  engineers,  therefore, 
had  little  opportunity  to  influence  the  simulation  characteristics.  In  May 
1987,  at  the  suggestion  of  TRAC-WSMR,  USAEs  requested  modeling  support  from 
TRADOC  for  a  detailed  countermobility  study.  The  purpose  of  this  study  is 
fourfold: 

(1)  To  measure  a  countermobility  system's  effectiveness  and  to 
quantify  its  effectiveness  in  terms  of  combat  vehicle  equivalents.  That  is, 
to  try  to  answer  questions  such  as,  "How  many  combat  vehicles  is  a  minefield 
worth? " 

(2)  To  add  appropriate  decision  tables  for  countermobility 
systems  and  test  CASTFOREM  with  these  decision  tables  in  place. 

(3)  To  evaluate  the  simulation  value  of  modeling  minefields, 

other  countermobility  systems,  and  breaching  systems.  In  other  words,  will 

the  countermobility  module  add  significant  realism  to  the  simulated  combat? 
Will  it  do  so  at  an  acceptable  cost  in  added  computer  run  time? 

(4)  To  convince  the  TRADOC  modeling  community  that  the  updated 
countermobility  module  is  a  valuable  analytic  tool  that  should  be  included  in 
TRADOC  standard  scenarios. 

i.  Other  agencies  that  have  copies  of  CASTFOREM  are  Harry  Diamond 

Laboratories,  US  Army  Missile  Command,  and  the  US  Army  Armament  Research 


Development  Engineering  Center.  The  Infantry  School  at  Fort  Benning,  Georgia, 
also  has  its  own  version  of  CASTFOREM;  it  simulates  dismounted  infantry  as 
well  as  vehicles .  Although  these  agencies  use  their  modified  versions  of  the 
model  for  internal  studies,  the  only  model  which  enjoys  official  Army  sanction 
is  the  floor  model  at  TRAC-WSMR. 

5.  Approach .  This  analysis  relies  on  information  gleaned  from  docu¬ 
ments  and  interviews. 

a.  The  primary  source  was  the  five  volumes  of  CASTFOREM 
documentation.^  Various  briefing  graphics  supplemented  these  primary 
information  sources. 

b.  ESC  analysts  interviewed  representatives  from  the  Simulation 
Support  Division,  TRAC-WSMR,  and  the  Directorate  of  Combat  Developments  (DCD) , 
USAES . 


^CASTFOREM :  Executive  Summary;  CASTFOREM :  User  Input  Guide;  CASTFOREM : 
Scenario  Writers  Guide;  CASTFOREM :  Pos t -  processor  Guide;  CASTFOREM: 
Methodologies  (TRAC-WSMR,  February  1988). 
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II.  DESCRIPTION  OF  THE  MODEL 


6.  Simulated  Terrain  and  Physical  Environment.  Terrain  is  represented 
by  square  cells.  Normally,  each  cell  represents  a  square  of  terrain  measuring 
100  meters  by  100  meters  although  it  is  possible  to  use  50-meter,  25-meter,  or 
even  12. 5 -meter  cells.  The  use  of  the  higher  resolution  terrain  cells, 
however,  incurs  a  substantial,  often  prohibitive,  increase  in  model  run  time. 
Terrain  considerations  are  covered  in  detail  in  Annex  E. 


Each 

terrain  square  is  coded 

for : 

(1) 

Road  surfaces 

(2) 

Surface  features 

(3) 

Height  of  vegetation  and  built- 

•up  areas 

(4) 

Canopy  concealment 

(5) 

Hydrography 

(6) 

Cross-country  movement 

for  dry 

conditions 

(7) 

Cross-country  movement 

for  wet 

conditions 

(8) 

Ground  elevation 

(9) 

Obstacles 

b.  Movement  within  the  battlefield  is  controlled  through  a  system 
of  user-established  Movement-Control-Points  (MCPs) .  An  MCP  is  described  by 
X-Y-Z  coordinates  which  define  a  unique  location  on  the  battlefield.  They  are 
linked  by  the  user  to  form  networks  simulating  possible  routes  of  march 
(flight)  for  maneuvering  units. 

(1)  Ground  vehicles  are  constrained  by  the  mobility  charac¬ 
teristics  of  the  vehicle,  the  mobility  limitations  of  the  terrain  over  which 
the  vehicle  is  attempting  to  maneuver,  and  their  received  orders. 

(2)  Helicopters  are  constrained  by  their  inherent  climb  and 
descent  rates,  their  straight  and  level  flight  rates,  and  also  by  their 
received  orders. 

c.  Line  -  of - s ight  modeling  considers  both  ground  elevation  and 
vegetation  heights.  The  model  degrades  visibility  for  generator- induced 
combat  obscurants.  The  CASTFOREM  currently  plays  both  vehicle-generated  and 
artillery-delivered  smoke. 

d.  Suppression  of  enemy  movement  and  return  fire  by  direct-firc  and 
indirect- fire  weapons  are  modeled  through  both  generic  decision  tables  and 
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special  algorithms.  CASTFOREM  is  flexible  enough  to  accommodate  emerging 
suppression  techniques  and  effects. 

e.  Targets  are  acquired  by  either  visual  or  laser  devices.  Visual 
acquisition  depends  on  ambient  light  levels,  observer  movement,  target  back¬ 
ground,  and  observer  viewing  time.  The  ability  of  laser  devices  to  acquire 
targets  depends  on  the  amount  of  energy  returned  by  the  target. 

f.  Direct-fire  engagements  are  explicitly  modeled,  fire  system 
against  fire  system. 

g.  In  CASTFOREM,  the  trajectory  and  the  damage  caused  by  artillery 
rounds  or  rockets  are  explicitly  modeled.  Normally,  artillery  units  are 
implicitly  prepositioned  in  static  firing  positions,  most  often  located  out¬ 
side  the  confines  of  the  battlefield  mapped  by  the  model.  Although  the  model 
can  track  the  projectiles  of  individual  artillery  tubes,  support  missions  are 
usually  fired  as  batteries,  battalions,  or  regiments  in  order  to  minimize  the 
modeling  run  times.  Only  those  projectiles  which  land  within  the  immediate 
vicinity  of  units  are  tracked  by  the  model  --  another  modeling  shortcut  which 
reduces  computer  run  time. 

h.  Helicopters  are  explicitly  modeled  in  both  their  reconnaissance 
role  and  their  direct-fire  role.  Helicopters  can  either  acquire  targets  for 
themselves  or  for  other  weapons  systems.  In  the  case  of  laser-guided  mis¬ 
siles,  they  can  direct  either  their  own  missiles  or  those  of  another  heli¬ 
copter. 

i.  CASTFOREM  emphasizes  combat  between  vehicles  and  rarely  plays 
dismounted  infantry  actions.  Although  the  model  is  fully  capable  of  playing 
individual  soldiers,  study  propor-nts  typically  ask  TRAC-WSMR  to  play  only 
those  infantry  weapons  systems  that  have  a  significant  anti-armor  or  anti¬ 
vehicle  impact,  such  as  TOW  and  SAGGER  missile  systems.  Even  such  prevalent 
anti-armor  systems  as  LAWs ,  Dragons,  and  their  Warsaw  Pact  counterparts  are 
normally  excluded  from  the  CASTFOREM.  The  exclusion  of  dismounted  infantry 
from  model  runs  substantially  decreases  the  computer  run  time. 

j.  CASTFOREM  models  communications  between  units.  The  communi¬ 
cation  can  be  perfect  or  it  can  be  degraded  to  reflect  a  variety  of  combat  or 
equipment  limitations. 

k.  The  effects  of  nuclear,  biological,  chemical  (NBC)  warfare  are 
modeled  implicitly  by  degrading  acquisition  times,  hit  probabilities. 
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communication  times,  and  movenent  rates.  Degradation  rates  are  all  specified 
by  the  user. 

7.  Units  that  Operate  in  this  Environment.  The  size  of  the  opposing 
forces  modeled  has  no  artificial  limits.  However,  most  model  runs  play  one 
company- sized  defender  against  a  reinforced  battalion.  Because  engagements 
are  executed  at  the  level  of  the  individual  weapon  system,  larger  force 
structures  resist  successful  analyses  by  generating  overwhelming  amounts  of 
data . 

a.  CASTFOREM  explicitly  models  the  maneuver  and  engagement  outcomes 
for  individual : 

(1)  Direct-fire  ground  weapons  systems 

(2)  Ground  vehicles 

(3)  Helicopters 

b.  CASTFOREM  gives  the  user  the  flexibility  of  designing  virtually 
any  unit  structure.  Since  the  level  of  resolution  is  at  the  individual  weapon 
system,  unit  composition  is  unlimited  --  from  an  individual  soldier  with  his 
weapon  to  a  multi -vehicle  force.  The  composition  of  the  opposing  forces  is 
limited  only  by  the  size  of  the  computer  memory. 

c.  CASTFOREM  provides  the  capability  for  modeling  artillery  sup¬ 
porting  fires.  The  locations  of  artillery  units,  preplanned  targets,  and 
forward  observers  are  usually  established  before  the  game  run.  During  the 
run,  the  acquisition  of  targets  is  portrayed  explicitly  through  decision 
tables . 

8 .  Functional  Processes  or  Operations  Performed  by  the  Units. 

a.  To  support  the  activities  of  the  various  units  being  modeled, 
CASTFOREM  also  explicitly  models  through  a  variety  of  user-defined  algorithms 
and  decision  tables: 

(1)  Command  and  communications.  To  perform  actions,  units  must 
receive  commands  from  higher  authorities  (from  vehicle  commanders  up  to 
regimental  commanders) .  Units  which  observe  something  also  must  successfully 
communicate  the  discovery  to  others  before  such  knowledge  can  be  shared.  The 
model  can  play  a  variety  of  radio  types  and  mixes  which  are  affected  by 
battlefield  conditions. 

(2)  Maneuver.  Through  command  and  decision  tables,  the  com¬ 
puter  moves  units  along  predefined  routes  of  march.  The  decision  table  format 
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accommodates  dynamic  changes  of  both  routes  and  march  formations  by  units 
faced  with  combat  crises. 

(3)  Search  for  and  acquire  targets.  Individual  crew  members  of 
weapon  systems  search  for  and  acquire  targets.  When  predetermined  conditions 
are  satisfied  by  the  crewman  and  his  potential  target,  the  crewman  acquires 
the  target. 

(4)  Engagement  results.  Engagements  result  in  kills,  damage, 
mobility  kills,  suppression  of  return  fire  or  maneuver  capability,  or  no 
effect.  Engagement  results  are  determined  by  the  type  of  round;  angle  of 
attack;  slope,  thickness,  and  angle  of  the  defensive  armor;  speed  of  the 
target;  visibility;  and  speed  of  the  firing  platform. 

(5)  Requests  for  artillery  fire  support.  Units  can  be 
programmed  to  call  for  artillery  support  when  user-defined  conditions  are 
satisfied. 

(6)  Orders  to  fall  back.  Unlike  some  models  in  which  units 
continue  to  fight  until  the  last  man  is  killed,  CASTFOREM  accommodates  planned 
withdrawals.  Decision  tables  can  be  developed  which  will  call  for  the  with¬ 
drawal  of  units  when  predefined  conditions  are  satisfied. 

b.  CASTFOREM  monitors  ammunition  and  fuel  expenditures.  The  model 
can  also  play  rearming  and  refueling  of  units,  although  these  options  are 
rarely  used.  As  alternatives  to  detailed  modeling,  units  are  either  assumed 
to  have  unlimited  ammunition  and  fuel  or  they  are  rearmed  and  refueled 
implicitly  during  movement  between  positions. 

c.  Although  activation  of  supporting  artillery  fire  and  the 
accuracy  and  effect  of  the  impacting  rounds  are  modeled  in  great  detail,  the 
battery  firing  positions  are  normally  plotted  outside  the  boundaries  of  the 
battlefield  terrain  sector.  Counter-battery  engagements  are  not  modeled,  nor 
is  artillery  unit  displacement. 


III.  ANALYSIS  OF  ENGINEER  REPRESENTATION 


9.  Desired  Level  of  CASTFOREM  Engineer  Play.  An  assessment  of  the 
level  of  engineer  play  appropriate  for  the  model  depends  on  what  types  of 
studies  the  model  supports,  the  needs  of  the  analytic  community,  and  some 
measure  of  the  relative  impact  of  engineer  activities  on  the  other  game  com¬ 
ponents.  CASTFOREM  should  play  engineer  combat  with  sufficient  realism  to 
support  the  combat  development  needs  of  the  Engineer  School.  To  this  end,  it 
must  be  detailed  enough  to  discriminate  between  competing  developmental 
material  items.  However,  it  must  continue  to  support  the  study  needs  of  the 
other  service  branches.  The  enhancements,  therefore,  should  not  be  so 
detailed  that  the  run  time  increases  without  a  concurrent  increase  in  gaming 
realism. 

a.  General.  The  increased  number,  acceptance,  and  availability  of 
other  high- resolution  models  have  freed  CASTFOREM  from  some  of  the  higher - 
priority  requirements  which  precluded  access  by  the  Engineer  School. 

(1)  The  countermobility  study  was  initiated  by  USAES ,  at  the 
suggestion  of  TRAC-WSMR,  so  that  engineer  modeling  support  could  be 
incorporated  into  the  TRAC-WSMR  project  schedule.  The  stated  purpose  of  the 
study  is  to  "analyze  the  effects  and  combat  power  that  minefields  provide  in  a 
combined  arms  conflict. Most  of  the  remaining  modeling  time  is  used  to 
support  study  requests  from  the  combat  branch  schools  (US  Army  Armor  Center, 

US  Army  Infantry  School,  and  US  Army  Field  Artillery  School),  and  the  Combined 
Arms  Center. 

(2)  CASTFOREM  should  respond  to  the  analytic  requirements  of 
various  TRADOC  users.  To  be  acceptable  as  an  analytic  tool,  the  model  must 
reflect  a  realistic  battlefield  environment.  The  need  for  realism,  however, 
must  be  balanced  against  the  desire  for  reasonable  model  response  time.  If 
too  much  time  is  required  to  prepare  the  model's  battlefield  environment  and 
decision  tables,  or  if  the  new  coding  demands  excessive  amounts  of  computer 
run  time,  then  the  realism  gained  will  be  much  less  attractive  to  the  analytic 
community.  This  is  a  particularly  important  consideration  in  the  CASTFOREM 


Project  Coordination  Sheet,  signed  by  COL  F.  Parker,  US  Army  Engineer 
School  (USAES),  on  27  May  1987,  and  by  Mr.  H.  McCoy,  TRAC-WSMR,  on  1  June  1987. 
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environment,  because  each  study  supported  by  the  model  requires  from  12  to  20 
separate  runs  of  each  study  alternative  scenario;  and  it  is  not  uncommon  to 
have  as  many  as  five  such  alternatives.  (When  using  a  stochastic  model, 
multiple  runs  are  essential  to  eliminate  aberrant  results  from  consideration.) 

(3)  The  engineer  task  modeled  must  have  a  direct  and  measurable 
impact  on  the  units  or  on  other  combat  activities.  The  engineers  must  be  able 
to  complete  the  task  within  the  span  of  time  modeled  by  CASTFOREM  --no  longer 
than  2  hours.  CASTFOREM  plays  a  short  battle  that  precludes  representation  of 
a  great  many  engineer  tasks . 

b.  Engineer  forces.  The  task  force  organizations  played  in 
CASTFOREM  range  in  size  up  to  battalion.  The  largest  contingent  of  engineers 
which  would  typically  be  gamed  is  an  engineer  platoon.  In  addition  to  the  six 
engineer  vehicles,  other  non-engineer  vehicles  would  be  doing  engineer-related 
activities  (e.g.,  tank  plows  used  to  breach  minefields).  An  average  of  about 
15  vehicles  would  be  ' ffected  directly  by  engineer  and  engineer- like  task 
enhancements . 

c.  Engineer  tasks.  Engineer  tasks  are  discussed  in  detail  in 
Annex  F.  For  the  purposes  of  this  analysis,  only  those  tasks  which  have  a 
direct,  immediate,  and  local  impact  on  local  battalion  task  force  combat 
operations  are  examined. 

(1)  Countermobility. 

(a)  Engineer  emplacement  of  systems.  Reinforcing  the 
terrain  immediately  to  the  front  of  defending  units  usually  occurs  several 
hours  before  contact  by  opposing  forces.  Most  linear  minefields,  anti-tank 
ditches,  and  complex  obstacle  systems  would  be  completed  long  before  the 
beginning  of  the  conflict  depicted  in  CASTFOREM.  Modeling  the  effort 
associated  with  emplacing  2,000  to  4,000  meters  of  obstacles  and  minefields 
needed  for  a  company  defense  would  increase  the  battle  time  by  several  hours 
or  up  to  several  days.  The  large  time  variance  reflects  the  flexibility  of 
the  commander  to  allocate  scarce  engineer  resources  based  on  his  battlefield 
priorities.  Accommodating  the  play  of  engineer  emplacement  tasks  is  not  a 
realistic  goal  for  CASTFOREM  managers. 

(b)  Engineer  weapons  system  activation.  The  CASTFOREM 
modeling  community  should,  however,  consider  enhancements  to  the  model  which 
would  realistically  portray  the  activation  of  dynamic  countermobility  systems 
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such  as  RAAMS .  The  instantaneous  creation  of  an  anti-tank  minefield  on  top  of 
a  maneuvering  formation  limits  the  maneuver  commander  to  options  different 
from  those  he  would  consider  when  faced  with  a  pre-emplaced  minefield  to  his 
front.  Although  similar  to  RAAMS  in  its  means  of  delivery,  the  ADAM  system, 
because  of  its  anti-personnel  nature,  is  not  appropriate  for  modeling  con¬ 
sideration.  The  MOPMS  minefield  package  is  usually  activated  before  the 
arrival  of  enemy  forces  and,  from  a  modeling  standpoint,  displays  counter¬ 
mobility  characteristics  similar  to  those  of  a  conventional  minefield. 
Therefore,  expenditure  of  effort  to  model  the  activation  of  the  MOPMS  system 
and  the  delivery  of  its  minefield  package  is  not  appropriate.  The  question  of 
whether  or  not  to  model  the  activation  of  the  WAM  anti -vehicle  mine  system 
depends  on  the  characteristics  of  the  system  once  developed  and  fielded. ^ 

(c)  Effects  of  the  engineer  system  on  vehicles  and  weapons 
systems.  Detailed  modeling  of  the  effects  of  countermobility  systems  on  an 
attacking  force  is  critical  to  battlefield  realism.  Minefields,  tank  ditches, 
and  other  systems  can  be  devastating  to  a  well-orchestrated  mobile  assault  by 
disrupting  the  integrity  of  the  attacking  formations  and  slowing  the  tempo  of 
the  attack.  Commanders  who  fail  to  make  breaching  equipment  readily  acces¬ 
sible  within  their  attacking  formations  will  run  the  risk  of  additional 
losses.  The  model  should  consider  such  eventualities.  Failure  to  consider 
these  potential  effects  during  combat  modeling  gives  distorted  combat  results. 

(2)  Survivability. 

(a)  Engineer  emplacement.  Building  fighting  positions  for 
weapons  systems  and  protective  positions  for  soft  targets  are  engineer 
activities  that  occur  well  before  opposing  forces  engage  in  combat.  For  this 
reason,  modeling  such  activities  is  not  appropriate  for  CASTFOREM. 

(b)  Effects  of  the  positions  on  vehicles  and  weapons 
systems.  The  ability  of  a  weapons  crew  to  acquire  and  hit  a  target  is 
directly  affected  by  the  existence  or  lack  of  protective  positions.  The 
advantages  enjoyed  by  a  force  using  good  cover  and  concealment  over  a  force  in 

^ADAM  (Area  Denial  Artillery  Munition)  is  an  artillery-delivered,  anti¬ 
personnel  scatterable  mine  system.  RAAMS  (Remote  Anti-Armor  Mine  System)  is 
an  artillery-delivered,  anti-armor  scatterable  mine  system.  MOPMS  (Modular 
Pack  Mine  System)  is  a  command- initiated,  scatterable  mine  system.  WAM  (Wide 
Angle  Mine)  is  a  sensor- initiated,  anti-armor  mine. 


the  open  are  well  documented.  Realistic  wargaming,  therefore,  demands  that 
the  effect  of  survivability  positions  should  be  part  of  the  CASTFOREM  battle 
play. 

(3)  Mobility. 

(a)  Engineer  construction.  Engineer  construction  and 
repair  of  combat  roads  and  trails  and  activities  associated  with  forward 
aviation  combat  engineering  are  not  appropriate  for  CASTFOREM  modeling.  These 
activities  would  occur  well  in  advance  of  the  time  period  modeled  by  the 
CASTFOREM  and,  therefore,  should  not  be  modeled. 

(b)  Effects  on  vehicles  and  weapons  systems  caused  by 
having  or  not  having  engineer  construction  support.  Adverse  effects  on  combat 
units  caused  by  the  engineers'  failure  to  complete  these  tasks  occur  after  a 
substantial  passage  of  time.  Also,  the  effects  tend  to  be  felt  more  by  the 
combat  support  and  service  support  elements  than  directly  by  combat  units; 
this  makes  quantitative  measurement  difficult.  These  effects,  therefore,  are 
not  candidates  for  modeling. 

(c)  Counter-obstacle  activities.  Neutralizing  the 
deleterious  effect  of  obstacles  on  combat  formations  is  an  extremely  important 
battlefield  activity.  Breaching  minefields,  walls,  abatis,  and  obstacle 
fields;  and  traversing  anti-tank  ditches  and  small  gaps  are  all  battlefield 
activities  that  can  occur  within  the  boundaries  of  CASTFOREM 's  time  frame. 

Both  engineer  forces  and  non-engineer  maneuver  elements  play  a  role  in  breach¬ 
ing  obstacles  to  movement.  Assaulting  formations  are  task  organized  with 
counter-obstacle  needs  in  mind.  An  enhanced  counter-obstacle  module  is 
essential  to  examine  both  the  effectiveness  of  individual  breaching  systems 
and  proper  mix  of  breaching  systems  within  the  task  force  organization. 

1.  Breaching  minefields.  Because  of  the  emphasis  on 
mine  warfare  by  modern  armies,  it  is  essential  that  CASTFOREM  realistically 
model  countermine  activities. 

2.  Traversing  anti-tank  ditches.  The  need  to  quickly 
traverse  anti-tank  ditches  and  short  gaps  with  launched  bridging  is  prevalent 
on  today's  battlefield.  CASTFOREM  needs  to  accommodate  these  activities. 
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3.  Breaching  roadblocks  and  obstacle  fields.  Breach¬ 
ing  roadblocks  (e.g.,  craters  and  abatis)  and  obstacle  fields  are  activities 
which  are  good  candidates  for  CASTFOREM  modeling. 

(d)  River  crossing  operations.  Deliberate  gap  crossings 
and  river  crossings  are  not  modeling  candidates.  There  are  two  reasons  for 
this.  First,  deliberate  gap  crossings  are  lengthy  activities  that  usually 
require  assistance  from  higher  level  engineer  assets.  Higher  level  engineer 
units  are  usually  not  depicted  in  the  CASTFOREM  environment.  Second,  these 
crossings  are  normally  attempted  only  after  both  banks  are  secured  by  friendly 
forces  or  the  far  bank  is  held  only  by  weak  enemy  forces. ^  Incorporating  a 
deliberate  crossing  would  necessitate  simulating  airborne  and  air  assaults 
and  vehicle  swimming  and  snorkeling  capabilities  --  this  could  represent  a 
significant  increase  in  model  run  time.  Major  gap  crossing  endeavors  occur 
relatively  infrequently.  The  infrequency  strongly  suggests  that  deliberate 
gap  crossings  should  not  be  incorporated  into  the  general  usage  CASTFOREM 
model.  Modeling  of  such  crossings  would  be  more  efficiently  served  through 
another  model. 

d .  Summary . 

(1)  Figure  A-l  shows  the  priority  ranking  of  task  categories 
for  high-resolution  models  obtained  from  a  survey  of  Army  modelers,  engineers, 
and  maneuver  commanders.  The  details  of  this  survey  are  discussed  in  Annex  F. 
Using  this  task  ranking  as  a  starting  point,  ESC  developed  Figure  A-2  which  is 
a  list  of  tasks  relevant  to  the  CASTFOREM  model.  In  some  cases,  specific 
tasks  were  added  under  the  broad  task  categories  of  the  survey  (e.g.,  breach 
minefields  under  the  category  breach  obstacles  in  the  assault) .  In  other 
cases,  categories  were  dropped  because  they  were  beyond  the  scope  of  the  short 
CASTFOREM  battle  time  (e.g.,  improve  assault  breaches  for  follow-on  forces). 
The  second  column  of  Figure  A-2  shows  whether  the  actual  engineer  task 
necessary  to  construct,  emplace,  breach,  or  traverse  is  a  candidate  for 
CASTFOREM  enhancement.  The  third  column  shows  whether  the  effects  of  the 
system  should  be  incorporated  into  the  CASTFOREM  combat  environment.  For 
dynamic  minefield  systems,  a  fourth  column  shows  whether  the  activation  of  the 

^ Mobility ,  FM  5-101  (Department  of  the  Army,  1985),  p.  6-14. 


HIGH  RESOLUTION  MODELS 


OVERALL  TASK  RANKING 


Priorit; 

Task  Categories  Sorted  Ranking 

_ In  Priority  Order _ ('Percent 

Vital  Task  Group 

Prepare  fighting  positions  for  direct-fire  systems  12. 

Install  linear  obstacles  11. 

Breach  obstacles  in  the  assault  10. 

Install  point  obstacles  10. 

Prepare  positions  for  indirect- fire  &  other  systems  9. 

Conduct  river  crossing  operations  in  the  assault  8. 

Critical  Task  Group 

Improve  assault  breaches  for  follow-on  forces  5. 

Maintain  main  supply  routes  5 . 

Pioneer  trail  preparation  &  maintenance  5. 

Improve  river  crossing  sites  for  follow-on  forces  4. 

Forward  airlanding  facility  preparation  &  maintenance  4. 

Site  preparation  &  r..a  :  utenance  for  CS  &  CSS  units  4. 

Essential  Task  Group 

Rear  area  facility  rehabilitation  &  maintenance  2. 

Airfield  damage  repair  2. 

Necessary  Task  Group 

Other  (engineer  raids)  1. 

Port  &  waterfront  facilities  construction  &  repair  1. 


Figure  A-l 


REQUIRED  ENGINEER  REPRESENTATION  IN  CASTFOREM 


■ 

CASTFOREM 

Engineer  Task  Task 

Should  Model 
Effects 

SURVIVABILITY 

- 

Prepare  fighting  positions 
for  direct-fire  systems 

X 

Prepare  positions  for  indirect- 
fire  and  other  systems 

X 

MOBILITY 

Breach  obstacles  in  the  assault: 

-Breach  minefields  X  X 

-Breach  obstacle  fields  X  X 

-Breach  road  craters  X  X 

-Breach  expedient  obstacles  X  X 

-Cross  antitank  ditches  X  X 

-Cross  short  gaps  with  X  X 

assault  bridging 

-Breach  complex  obstacles  X  X 


Conduct  river  crossing 

operations  in  the  assault 

COUNTERMOBILITY 
(Pre-emplaced  Systems) 


Install  point  obstacles: 

-Emplace  point  mines  -  X 

-Crater  roads  and  trails  -  X 

Install  linear  obstacles: 

-Emplace  a  conventional  minefield  -  X 

-Emplace  a  GEMSS  minefield  X 

-Emplace  a  Volcano  minefield  -  X 

-Dig  antitank  ditches  -  X 

-Emplace  complex  obstacles  -  X 


Figure  A- 2  (Continued  on  Next  Page) 


REQUIRED  ENGINEER  REPRESENTATION  IN  CASTFOREM  --  CONTINUED 


COUNTLRMOBILITY 
(Dynamic  Systems) 


CASTFOREM  Should 

Model 

Engineer  Task 

Task 

Activation 

Effects 

Emplace  minefield  with: 
-RAAMS 

N/A 

X 

X 

-ADAMS 

N/A 

- 

- 

-MOPMS 

- 

X 

X 

-WAM 

- 

X 

X 

Figure  A-2 

mine  dispenser  or  the  delivery  of  the  mines  to  the  target  area  should  be 
modeled . 

10.  Actual  CASTFOREM  Play.  The  level  of  engineer  play  now  portrayed  in 
the  floor  version  of  the  CASTFOREM  battleground  falls  slightly  short  of  the 
desired  level  of  p1 ay 

a.  Survivability.  The  ability  to  acquire  and  hit  targets  occupying 
protective  positions  is  modeled  explicitly  through  direct  computations.  No 
further  refinements  to  this  category  are  needed. 

b.  Countermobility.  Currently,  minefield  patterns  are  generated 
randomly  and  the  effects  of  individual  mines  are  modeled  explicitly  through 
direct  computations.  The  model  can  replicate  the  minefield  patterns  that 
might  be  expected  from  any  of  the  current  delivery  systems.  CASTFOREM  uses 
decision  tables  to  treat  the  breaching  of  other  countermobility  systems  (e.g., 
tank  ditches  and  road  craters) . 

c.  Mobility.  The  breaching  module  clears  from  one  to  nine  lanes 
through  the  minefield.  The  lanes  may  be  cleared  without  benefit  of 
specialized  mine-clearing  equipment.  In  addition,  if  the  first  vehicle  in  the 
file  suffers  a  mobility  kill,  it  is  pushed  aside  by  following  vehicles.  Since 
the  following  vehicles  might  actually  go  around  the  disabled  one,  the  chance 
of  detonating  another  mine  would  increase. 

d.  Figure  A- 3  shows  how  the  current  floor  version  of  the  CASTFOREM 
plays  engineer  tasks  and  residual  effects. 


CURRENT  LEVEL  OF  ENGINEER  TASK  REPRESENTATION  IN  CASTFOREM 


CASTFOREM  Models 


Engineer  Task 


Effects 


SURVIVABILITY 


Prepare  fighting  positions  -  X 

for  direct-fire  systems 

Prepare  positions  for  indirect-  -  X 

fire  and  other  systems 

MOBILITY 


Breach  obstacles  in  the  assault: 

-Breach  minefields  X  X 

-Breach  obstacle  fields  X  X 

-Breach  road  craters  X  X 

-Breach  expedient  obstacles  X  X 

-Cross  antitank  ditches  X  X 

-Cross  short  gaps  with  X  X 

assault  bridging 
-Breach  complex  obstacles 

Conduct  river  crossing  X  X 

operations  in  the  assault 


COUNTERMOBILITY 
(Pre-emplaced  Systems) 

Install  point  obstacles: 

-Emplace  point  mines 
-Crater  roads  and  trails 

Install  linear  obstacles: 

-Emplace  a  conventional  minefield 
-Emplace  a  GEMSS  minefield 
-Emplace  a  Volcano  minefield 
-Dig  antitank  ditches 


CURRENT  LEVEL  OF  ENGINEER  TASK  REPRESENTATION  IN  CASTFOREM  -- 

CONTINUED 


COUNTERMOBILITY 
(Dynamic  Systems) 

CASTFOREM  Models 

Engineer  Task 

Task 

Activation 

Effects 

Emplace  minefield 

with: 

-RAAMS 

N/A 

X 

X 

-ADAMS 

N/A 

- 

- 

-MOPMS 

- 

X 

X 

-WAM 

“ 

- 

Figure  A- 3 

11.  Desired  CASTFOREM  Play.  Explicit  modules  will  increase  the  run 
time  but  may  provide  a  better  modeling  tool  to  evaluate  system  components. 
Implicit  modules,  on  the  other  hand,  usually  are  faster  and  may  be  sufficient 
if  the  performance  of  the  system  or  the  battle  results  are  unlikely  to  be 
skewed  by  the  lack  of  detailed  computations.  Another  concern  that  surfaces 
when  choosing  between  explicit  and  implicit  modeling  options  is  whether  the 
operation  of  critical  equipment  components  is  modeled  in  the  detail  needed  to 
discriminate  between  competing  systems.  Since  CASTFOREM  is  used  as  a  tool  for 
such  comparisons  and  to  examine  how  such  systems  can  be  variously  task 
organized  to  fit  particular  battlefield  situations,  the  level  of  modeling 
detail  is  most  important. 

a.  The  modules  which  model  minefields  and  antitank  ditches  can  be 
triggered  when  a  vehicle  encounter  occurs.  If  the  terrain  square  containing 
the  obstacle  is  never  entered  or  if  the  unit  chooses  to  bypass,  it  is  suffi¬ 
cient  to  know  only  that  an  obstacle  exists  in  the  square  --  detailed  modeling 
is  unnecessary.  Once  a  unit  undertakes  a  breaching  operation,  however,  the 
patterr  of  obstacle  components  and  mines,  the  boundaries  of  the  obstacle 
field,  and  the  operations  of  the  breaching  system  should  be  modeled  in  detail. 
Antitank  walls  and  wire  obstacles  need  not  be  modeled.  Walls  are  rarely  a 
part  of  the  defense  and  would  not,  therefore,  be  a  critical  impediment  against 


which  vehicles  and  weapons  systems  should  be  measured.  Wire  obstacles  have 
anti-personnel  characteristics  and  serve  little  value  in  a  wargame  which  plays 
only  vehicles  and  weapons  systems. 


b.  The  delivery  of  dynamically  delivered  obstacle  systems  should  be 
modeled  if  the  delivery  typically  occurs  in  conjunction  with  vehicle  against 
vehicle  combat.  The  artillery  delivered  scatterable  mine  systems,  for 
example,  can  deploy  a  minefield  in  the  same  location  as  that  occupied  by  a 
military  unit.  The  commander  of  the  target  unit  is  faced  with  a  different  set 
of  problems  than  is  the  commander  of  a  unit  approaching  a  minefield.  By-pass, 
for  example,  is  an  option  that  is  unavailable  to  the  first  unit  commander  -- 
his  unit  is  inside  the  minefield  and  he  must  breach  his  way  out.  On  the  other 
hand,  if  the  delivery  system  fails  to  deliver  the  obstacle  on  target  because 
of  component  failure  or  battle  -  induced  errors,  then  the  obstacle  will  have  no 
effect  on  the  target.  Detailed  modeling  of  both  the  delivery  and  the  system 
effects  is  essential  in  this  instance. 

12.  Required  Modifications.  As  Figure  A- 3  shows,  most  of  the  engineer 
tasks  are  currently  represented  to  the  ler  ol  of  detail  necessary  to  accurately 
portray  their  effects  on  the  overall  battle.8  Figure  A-4  lists  the  engineer 
enhancements  that  must  be  represented  for  CASTFOREM  to  realistically  portray 
battlefield  conditions  and  provide  a  vehicle  for  examining  engineer  systems. 


O 

Preliminary,  unpublished  results  of  the  TRAC-WSMR  test  of  the  mobility 
and  countermobility  decision  tables  indicate  that  CASTFOREM  accurately  models 
the  tasks  shown  in  Figure  A-3. 


NEEDED  ENGINEER  ENHANCEMENTS  TO  CASTFOREM 


CASTFOREM 

Should  Also  Model 

Engineer  Task  Task 

Effects 

SURVIVABILITY 

Prepare  fighting  positions 
for  direct-fire  systems 

- 

Prepare  positions  for  indirect- 
fire  and  other  systems 

- 

MOBILITY 

Breach  obstacles  in  the  assault 
-Breach  minefields 
-Breach  obstacle  fields 
-Breach  road  craters 
-Breach  expedient  obstacles 
-Cross  antitank  ditches 
-Cross  short  gaps  with 
assault  bridging 
-Breach  complex  obstacles 

Conduct  river  crossing 

operations  in  the  assault 

COUNTERMOBILITY 
(Pre-emplaced  Systems) 

Install  point  obstacles: 

-Emplace  point  mines 
-Crater  roads  and  trails 

Install  linear  obstacles: 

-Emplace  a  conventional  minefield 
-Emplace  a  GEMSS  minefield 

-Emplace  a  Volcano  minefield  -  X 

-Dig  antitank  ditches 

-Emplace  complex  obstacles  -  X 


Figure  A- 4  (Continued  on  Next  Page) 
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NEEDED  ENGINEER  ENHANCEMENTS  TO  CASTFOREM  --  CONTINUED 


COUNTERMOBILITY 
(Dynamic  Systems) 

CASTFOREM  Should  Also  Model 

Engineer  Task 

Task 

Activation  Effects 

Emplace  minefield 
-RAAMS 

-ADAMS 

-MOPMS 

-WAM 

with : 

N/A 

N/A 

X  X 

Figure  A-4 
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IV.  ANALYSIS  OF  MODIFICATIONS 


13.  Modeling  Approach.  The  decision  to  explicitly  simulate  a  function 
within  CASTFOREM  must  weigh  the  relative  increased  accuracy  of  the  battlefield 
portrayal  against  a  potential  increase  in  model  run  time.  The  initial 
determination  to  choose  an  explicit  simulation  method  over  an  implicit  method 
is  based  on  parameters  that  do  not  lend  themselves  to  rigorous  quantitative 
analysis.  Any  decision  at  this  point  must  be  based  on  intuitive  reasoning. 
Once  each  new  module  has  been  developed  enough  to  be  incorporated  into  the  R&D 
CASTFOREM,  its  relative  merits  can  be  measured  by  running  CASTFOREM  both  with 
and  without  the  module  and  comparing  results. 

a.  As  suggested  in  Figure  A-4,  the  following  engineer  enhancements 
should  be  validated  and  incorporated  into  the  floor  version  of  CASTFOREM:  (1) 
minefield  patterns  which  result  from  conventional  mine-laying  techniques, 
dynamic  mine-dispensing  systems,  Volcano,  MOPMS ,  and  GEMSS;  (2)  roller/plow, 
line  charge,  and  force- through  breaches  of  minefields;  (3)  anti-tank  ditch  and 
short  gap  crossings;  (4)  breaching  road  craters;  and  (5)  overcoming  combina¬ 
tions  of  obstacles.  Developmental  systems  which  are  designed  to  have  a  direct 
and  immediate  effect  on  vehicles  conducting  assault  operations,  such  as  WAM, 
should  be  simulated  explicitly  as  soon  as  an  appropriate  data  base  can  be 
developed. 

b.  Figure  A-5  suggests  how  accurate  and  realistic  engineer  repre¬ 
sentation  can  be  developed  in  two  phases.  The  first  phase  is  a  continuation 
of  the  USAES  effort,  initiated  with  TRAC-WSMR  in  May  1987,  to  measure  the 
combat  power  of  minefields.  This  study  will  result  in  an  effective  addition 
to  the  current  simulation  and,  perhaps  more  important,  will  lead  to  a  general 
recognition  and  acceptance  by  TRAD'JC  users  of  the  value  of  engineer  represen¬ 
tation  to  the  overall  model's  effectiveness.  This  phase  includes  the  addition 
of  engineer  activities  associated  with  mines,  antitank  ditches,  short  gaps, 
and  road  craters.  Although  TRAC-WSMR  has  validated  the  new  code  and  decision 
tables,  it  has  yet  to  publish  the  results.  The  second  phase  should  start  when 
the  first  phase  is  complete  and  would  add  WAM,  dynamic  delivery  of  mines  by 
artillery  or  air,  and  obstacle  combinations.  The  engineer  community  should 
aggressively  pursue  modifications  to  the  R&D  CASTFOREM,  with  a  view  to 
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MODELING  APPROACH 

--  CASTFOREM  ENGINEER  REPRESENTATION 

Specific  Activity 

Specific  Modeling  Requirements 

_* 

Phase  1* 

Minefield  effects 

Explicitly  simulate  patterns  for  minefields 
emplaced  with  conventional  methods,  Volcano, 

GEMSS,  and  MOPMS .  Maintain  the  detailed 
computational  module  which  plays  different  mine 
characteristics . 

- 

Minefield  breaching 

Explicitly  simulate  breaching  minefields  using 
force  through,  roller/plow,  and  line  charges. 

Must  allow  for  breaching  multiple  lanes  through 
the  obstacle. 

Antitank  ditch  effects 

Explicitly  simulate  rectangular- ,  triangular- , 
and  sidehill-cut  antitank  ditches. 

Antitank  ditch  breaching 

Explicitly  simulate  crossing  at  several 
locations . 

Short  gap  effects 

Model  the  effects  of  gaps  less  than  18  meters 
wide  using  detailed  modeling  techniques. 

Short  gap  crossing 

Concentrate  on  modeling  tactical  bridging 
techniques  such  as  vehicular- launched  bridges 
and  pre- fabricated  air- transported  bridging. 

Road  crater  effects 

The  module  should  simulate  craters  of  varying 
widths  and  depths  emplaced  by  using  either 
equipment  or  explosives. 

Road  crater  breaching 

The  module  should  simulate  force  through 
breaching  and  breaching  with  the  use  of  special 
equipment  (e.g.:  AVLB) . 

— 

Most  of  the  effort  in  Phase  1  will  be  directed  at  validating  model ing 
code  and  decision  tables  which  are  already  in  CASTFOREM. 

Figure 

A- 5  (Continued  on  Next  Page) 
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MODELING  APPROACH 


CASTFOREM  ENGINEER  REPRESENTATION 


CONTINUED 


Specific  Activity 

Specific  Modeling  Reauirements 

Phase  2** 

Dynamic  delivery  of 

mines 

Direct  modeling  techniques  should  be  used  to 
simulate  the  delivery  of  mines  by  artillery, 
air,  or  other  methods  onto  an  enemy  force. 
Special  consideration  must  be  given  to  the 
enemy's  reaction  to  a  delivery  of  dynamic  mines. 

WAM  effects 

Stand-off,  projectile  delivery  systems  should  be 
modeled  explicitly.  The  module  should  play  the 
activation  of  the  firing  mechanism  as  well  as 
the  flight  and  explosive  characteristics  of  the 
proj  ectile . 

Obstacle  combinations 

The  module  should  simulate  various  combinations 
of  countermobility  systems  that  can  realis¬ 
tically  occur  within  a  100  meter  by  100  meter 
terrain  cell  (e.g.  two  parallel  minefields  and 
an  antitank  ditch  seeded  with  mines) . 

Phase  2  will  require 
created  and  that  existing  c 

that  some  new  coding  and  decision  tables  be 
oding  and  decision  tables  be  validated. 

Figure  A- 5 


incorporate  successes  into  the  floor  version.  Work  on  the  various  engineer 
modules  must  be  scheduled  in  a  manner  that  does  not  interfere  with  CASTFOREM 
studies  initiated  by  USAES  which  support  their  combat  development  activities. 

14.  Ease  of  Modeling.  USAES  and  TRAC-WSMR  have  developed  the 
simulation  logic,  the  coding,  and  the  decision  tables  for  a  large  part  of  the 
Engineer  Module.  Once  the  results  are  published  for  the  countermobility 
study,  USAES  and  TRAC-WSMR  will  have  made  substantial  progress  toward 
adequately  representing  engineers  in  CASTFOREM. 

15.  Resources  Required.  The  engineer  cell  at  TRAC-WSMR  has  both  the 
experience  and  the  modeling  knowledge  to  provide  adequate  support  to  the 
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effort.  Figure  A-6  depicts  the  estimated  professional  staff  years  of  effort 
that  are  required  by  TRAC-WSMR  and  USAES  to  complete  the  tasks  within  each 
phase . 


MANPOWER  REQUIREMENTS 
(Professional  Staff  Years) 


WSMR 

USAES 

ESC 

Phase  1 

Complete  ongoing  study  for  USAES, 
validate  decision  tables,  and 
publish  results. 

0.25 

0.25 

0.25 

Phase  2 

Develop  coding  for  WAM, 
dynamic  mine  delivery, 
and  obstacle  combinations. 

0.25 

0.25 

0.25 

Figure  A-6 

16.  Impact  on  Model .  History  suggests  that  engineer  battlefield 
systems  are  significant  factors  influencing  the  outcome  of  the  battle.  It  is 
reasonable  to  assert  that,  without  adequate  simulation  of  such  engineer 
systems,  CASTFOREM  provides  unrepresentative  conflict  results.  CASTFOREM 
should  reflect  the  results  of  a  well-placed  obstacle  on  a  determined  attacker 
who  lacks  sufficient  breaching  equipment. 

a.  Any  additions  to  the  current  model  are  likely  to  increase  its 
computer  run  time.  It  is  incumbent  on  the  engineer  modeling  community  to 
insure  that  the  increased  run  time  is  balanced  by  a  requisite  increase  in 
combat  realism.  Otherwise,  the  engineer  modules  will  not  be  used  during 
future  study  runs  and  engineers  will  continue  to  be  under-represented  in  this 
modeling  arena. 

b.  The  modeling  community  in  general  must  not  allow  basic  program¬ 
ming  concerns  such  as  requirements  for  additional  coding,  increased  run  times, 
and  increased  difficulty  for  scenario  writers  to  drive  the  decision  to  add  or 
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delete  engineer  modules.  The  key  consideration  must  be  whether  the  model 
enhancement  measurably  increases  combat  realism. 

c.  The  enhancements  currently  under  development  to  support  the 
countermobility  study  do  not  appear  to  extend  the  R&D  model  run  times  to  any 
significant  degree.  All  of  the  Phase  1  enhancements  use  virtually  the  same 
modeling  logic  and  coding.  Their  addition  to  the  floor  model  should 
significantly  increase  combat  realism  at  a  small  cost  in  increased  run  times. 
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I .  INTRODUCTION 


1.  Purpose .  This  annex  analyzes  the  engineer  representation  of  the 
Vector- in-Commander  (VIC)  Combat  Simulation  Model  and  recommends  enhancements 
to  it  under  the  hierarchy  of  Army  combat  simulation  models  and  the  Army  Model 
Improvement  Program  (AMIP) . 

2.  Scope .  This  annex  examines  VIC  in  order  to  determine  how  to  best 
improve  its  engineer  representation.  Recommended  enhancements  to  the  model 
are  based  on  the  model's  intended  use  within  the  hierarchy  of  the  Army's 
simulation  models,  the  AMIP  concept,  and  the  resources  needed  to  improve  the 
model.  This  annex: 

a.  Describes  the  background,  general  characteristics,  and  use  of 
VIC.  This  examination  is  based  on  VIC  Reference  (release)  1.0,  including  the 
Reference  version  1.1  released  in  October  1987  and/or  version  1.2  released  in 
March  1988. 

b.  Analyzes  the  representation  of  engineer- related  functions  and 
tasks  in  VIC  and  compares  it  with  the  desired  level  of  representation  as  the 
Army's  mid-resolution,  combat  simulation  model.  Specific  engineer- related 
data  sets  that  have  been  used  by  studies  using  VIC  are  not  examined.  The 
terrain  data  used  by  VIC  are  analyzed  in  Annex  E,  "Terrain  Data  Base 
Analysis,"  of  this  report. 

c.  Identifies  proposed  improvements  to  VIC,  describes  the  impacts 
associated  with  those  improvements,  and  estimates  the  resources  needed  to 
implement  them. 

3 .  Model  Background . 

a.  History  of  development.  In  1982,  TRADOC  established  a  require¬ 
ment  for  a  corps-level  model  in  which  AirLand  Battle  Doctrine  could  be 
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represented  and  studied.  The  following  modeling  requirements  for  AirLand 
Battle  were  not  available  in  the  Army's  existing  models: 

Maneuver  and  fight  in  all  directions 

Represent  command  and  control  staff  function 
impacts  on  decisions 

Represent  decision-making  at  different  levels 

Represent  the  perceived  situation  for  decision¬ 
making 

Employ  electronic  warfare  systems 

Employ  chemical  and  nuclear  munitions 

Represent  engineer  functions,  including  mine¬ 
fields 

Represent  recovery  and  return-to-duty  of 
damaged  vehicles 

TRAC-WSMR  (then  called  TRASANA)  decided  to  take  advantage  of,  and  improve 
upon,  the  best  features  of  existing  models  rather  than  to  develop  a  completely 
new  model.  TRAC-WSMR  selected  the  Vector-2  model  (developed  by  Vector 
Research,  Incorporated)  for  its  representation  of  ground  combat,  and  the 
USAF's  Commander  Model,  which  evolved  from  the  Talon  Model.  The  Commander 
Model  had  the  advantage  of  a  modular  structure  and  the  use  of  a  modern 
simulation  language,  SIMSCRIPT  II. 5.  Consequently,  VIC  was  developed  using 
the  structure  and  language  of  the  Commander  Model  (with  some  of  its  aspects  of 
air  combat)  and  a  modification  of  the  representation  of  ground  combat  from  the 
Vector- 2  Model.  Over  the  three  years  of  development  of  VIC  and  the  resulting 
combination  of  placing  Vector-2  attrition  methodologies  in  the  Commander  Model 
structure,  all  modules  were  eventually  revised  or  rewritten.  In  1985,  a 
review  committee  appointed  by  the  Army  Models  Committee  (AMC)  selected  VIC  as 
the  Army's  corps/division- level  model,  and  it  was  adopted  into  the  Army's 
hierarchy  of  combat  simulation  models  for  analysis  under  AMIP  in  1986, 
replacing  the  Corps/Division  Evaluation  Model  (CORDIVEM)  simulation. 

b.  VIC  configuration  management.  As  a  result  of  the  charter  for 
configuration  mary.'ir.ent  of  VIC,  the  VIC  Model  Proponent,  TRAC-WSMR, 
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established  the  VIC  Model  Users  Group  (VMUG).-'-  The  first  VMUG  meeting  was 
held  in  July  1987,  and  users  having  a  requirement  for  the  model  were  issued 
the  Reference  1.0  version  of  VIC.  VIC  1.1  was  issued  in  October  1987  and  VIC 
1.2  was  released  in  March  1988.  According  to  the  VIC  charter,  all  holders  of 
the  mode],  must  abide  with  the  configuration  control  policy.  VIC  users  may 
modify  their  copy  of  the  reference  VIC,  but  when  VIC  results  are  used  for 
briefings,  analysis,  or  reports  related  to  Army- sponsored  studies,  users  must 
indicate  the  reference  number  and  any  changes  made  to  the  reference  version  of 
VIC.  VIC  users  must  compare  new  input/output  against  the  reference  version, 
clearly  indicating  the  major  differences.  The  charter  also  states  that  TRAC- 
WSMR  will  review  and  evaluate  modifications  to  VIC  and  determine  the 
modifications  and  enhancements  to  be  included  in  new  reference  versions. 

c.  Use  of  VIC.  Figure  B-l  describes  the  studies  that  have  used,  or 
are  using,  VIC.  This  figure  identifies  the  study,  the  performing  agency,  the 
time  frame  when  the  analysis  was  performed,  the  VIC  release  version  used,  and 
scenario  used  for  the  analysis.  The  first  two  studies  performed  with  VIC  used 
the  pre-release  1.0  version.  Although  a  minefield  module  was  used  for  both  of 
these  studies,  this  version  did  not  have  the  capability  to  model  other 
engineer  unit  tasks  that  are  in  VIC  Release  1.0.  These  other  engineer  tasks 
were  modeled  implicitly  by  the  maneuver  unit  generating  the  requirement.  All 
the  studies  performed  with  VIC  since  the  introduction  of  Release  1.0  have  used 
the  Engineer  Module,  the  Minefield  Module,  and  the  portions  of  the  Terrain  and 
Barriers  Module  that  pertain  to  rivers  and  man-made  linear  obstacles.  These 
studies  have  simulated  about  three  to  six  days  of  combat.  Figure  B-l  also 
identifies  the  scenario  used  in  each  study  because  a  study  using  a  combat 
simulation  model  is  conducted  in  two  phases.  The  first  phase  involves  the 
selection  and  modeling  of  a  scenario.  The  second  study  phase  introduces  new 
parameters,  or  modifies  existing  data,  to  model  the  processes  of  particular 
interest  in  the  study. 

4.  Method  of  Analysis.  This  analysis  followed  five  steps: 

a.  First,  analyze  the  operations  that  are  modeled  and  data  require¬ 
ments  of  VIC.  Study  the  overall  model  structure  and  characteristics  of  the 


^■Charter  for  the  Configuration  Management  of  the  Vector- in-Commander 
(VIC)  Model  (TRAC-WSMR,  3  April  1987). 
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STUDIES  USING  THE  VIC  MODEL 


Studv  Name 

Performing 

Aeencv 

When 

Performed 

VIC 

Release  Used 

Scenario 

Used 

Battlefield  90 

TRAC-WSMR 

1984-1986 

Pre-release 

1.0 

JOBAS  III 
-  South 

Combined  Arms  Mission 

Area  Analysis  (CAMAA) 

TRAC-FLVN 

1987 

Pre -  release 
1.0 

Europe  6.0 

Armored  Family  of 

Vehicles  (AFV) 

TRAC-WSMR 

1987 

1.0 

Europe  6 . 3 

Forward  Area  Air  Defense 
System  (FAADS) 

TRAC-WSMR 

1987 

1.0 

Europe  6 . 5 

Deep  Fires 

TRAC-WSMR 

1987-1993 

1.0 

Europe  6 . 5 

Close  Combat  Capability 
Analysis  (CCCA) 

TRAC-FLVN 

1988 

1.1/1. 2 

Europe 

6.0/  6.2 

Figure  B-l 


various  force  component/capability  modules.  Develop  a  thorough  understanding 
of  VIC's  representation  of  engineer  units  and  engineer  operations.  This 
effort  relied  on  the  VIC  documentation  and  interviews  with  the  model 
developers  and  study  managers  using  VIC.^  The  analysis  of  VIC  documentation 
concentrated  on  six  VIC  modules  (engineer,  minefield,  terrain  and  barriers, 
global  ground,  ground  movement,  and  decision  tables)  because  of  their  direct 
impact  on  this  analysis. 

b.  Second  (as  a  parallel  effort),  establish  a  baseline  for  adequate 
engineer  representation  in  a  mid- resolution  ground  combat  simulation  model 
such  as  VIC  in  the  context  of  the  Army's  hierarchy  of  combat  simulation 
models . 

c.  Third,  assess  the  adequacy  of  VIC's  engineer  play  by  comparing 
its  current  capabilities  with  the  baseline  established  in  the  second  step. 

d.  Fourth,  recommend  actions  to  strengthen  the  engineer  representa¬ 
tion  in  VIC.  This  step  also  considers  VIC’s  design  objectives;  past,  current, 

^■VIC  Model  User  Guide,  draft  documentation  (TRAC-WSMR-TD,  June  1987). 
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and  projected  uses  of  VIC  in  analytic  studies;  and  the  relative  detail 
incorporated  in  the  engineer  representation  compared  to  the  detail  afforded 
other  force  components  and  operations.  This  phase  is  based  in  part  on  a  draft 
report  by  the  US  Army  Construction  Engineering  Research  Laboratory  (CERL) 
which  analyzed  the  engineer  representation  in  VIC.  That  report  was  sponsored 
by  the  AMIP  Management  Office  (AMMO) . ^ 

e.  Fifth,  analyze  the  impact  of  recommended  improvements  to  VIC. 
Estimate  the  resources  needed  to  implement  those  model  enhancements  and  rank 
the  improvements  for  incorporation  into  the  model. 


Analysis  of  the  Engineer 
Battle  Simulation  Model,  draft 


Representation  in  the  Vector  in  Commander  (VIC) 
Technical  Report  (CERL,  September  1987). 


II.  DESCRIPTION  OF  THE  VIC  MODEL 


5 .  General . 

a.  VIC  is  a  two-sided,  deterministic  computer  simulation  of  com!  at 
in  a  combined  arms  environment.  The  model  is  designed  to  provide  a  balanced 
representation  of  the  major  force  elements  in  a  tactical  campaign  of  a  US  Army 
corps  operating  in  a  theater  of  operations.  It  represents  friendly  air  and 
land  (blue)  forces  and  a  commensurate  enemy  (red)  force  in  a  mid- intens ity 
battle.  The  model  is  event-stepped  for  maneuver  elements  and  time-stepped  for 
calculating  support  effects.  The  model  can  run  in  either  an  interruptible 
mode  (for  model  development  and  scenario  analysis)  or  in  an  automatic,  batch 
mode  (for  study  production  runs).  The  model  has  a  set  of  preprocessors  for 
constructing  input  data  files  and  a  set  of  postprocessors  for  displaying  model 
results.  The  VIC  interactive  preprocessors  provide  automated  assistance  for 
building  or  modifying  the  VIC  force  structure,  deployment,  and  terrain 
database.  VIC  postprocessors  are  capable  of  graphics  output  displays  of 
combat  force  locations.  Eight  postprocessors  are  available  to  process 
specific  output  data  produced  during  a  simulation.  The  main  postprocessor  is 
capable  of  displaying  26  tables  of  output  data  such  as  plots  of  the  FEBA,  unit 
locations,  unit  strengths,  and  mine  assets.  Other  postprocessors  produce 
tables  for  specific  topics  such  as  logistics,  decision  tables,  and  minefields. 

b.  VIC  is  designed  to  operate  on  the  Digital  Equipment  Corporation 
(DEC)  series  of  VAX  computers  (VAX  11/780  as  a  minimum,  8800  series  is 
preferred)  installed  with  the  VMS  operating  system.  The  system  'onf iguration 
includes  RAMTEK  Corporation's  color  graphics  9460/65  system  which  is  used  for 
preprocessing  and  reviewing  model  output.  The  model  is  written  in  SIMSCRIPT 
II. 5,  and  the  preprocessor  is  written  in  ASCII  FORTRAN .  The  model  uses  about 
150,000  lines  of  code.  The  current  run  time  can  be  about  one  hour  of  computer 
time  for  each  three  hours  of  simulated  combat,  but  this  ratio  varies  depending 
ori  computer  equipment,  the  scenario  modeled,  and  number  of  active  modules. 
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chat  are  organic  Co,  or  have  an  influence  on,  the  capabilities  of  corps, 
divisions,  or  brigades.^ 

7.  Simulated  Terrain  and  Physical  Environment.  VIC  describes  terrain 
in  grid  squares.  There  are  no  limitations  on  the  size  of  the  grid  square,  and 
the  model  user  specifies  its  size.  TRAC-WSMR  and  TRAC-FLVN  both  use  a  "4  km 
by  4  km"  grid  system.  Figure  R-9  identifies  the  four  major  terrain  Taceois  in 
VIC.  The  number  of  terrain  categories  used  within  each  factor  is  also  user- 
dependent.  Barriers  and  water  obstacles  (rivers  and  other  streams)  are  repre¬ 
sented  by  line  segments  which  are  independent  of  the  grid  squares.  Roads  form 
a  linked,  node  network  which  are  used  only  by  logistic  units.  Although 
maneuver  units  do  not  take  advantage  of  the  logistic  road  network,  permitting 
faster  movement  rates,  their  routes  may  correspond  with  the  roads  in  the  area. 
Traf f icabil ity  and  intervisibility  parameters  are  associated  with  each  grid 
square.  Traff icability  is  a  function  of  day/night,  combat  intensity,  terrain, 
weather,  and  obstacles  that  are  encountered  on  the  path  of  a  maneuver  unit. 
Terrain  and  traf f icability  are  integrated  into  a  "combined  traf f icability 
index"  which  has  three  categories:  good,  fair,  or  poor.  Visibility  depends 
on  the  combined  effects  of  day/night,  weather,  line  of  sight,  and  smoke.  For 
a  more  detailed  discussion  of  terrain,  see  Annex  E,  "Terrain  Data  Base 
Analysis."  A  weather  cell  is  also  defined  over  a  grid  area.  Weather  changes 
according  to  a  predetermined  weather  chronology.  Weather  indices  represent 
cloud  cover  and  precipitation  type.  A  VIC  module  for  smoke  allows  maneuver 
and  artillery  units  to  disperse  smoke  that  affects  sensor  target  acquisition 
and  direct  fire  battle. 

8.  Ground  Force  Deployments.  Figure  B-3  identifies  the  unit  types  and 
unit  levels  that  can  be  modeled  in  VIC.  Although  the  size  of  any  unit  may  be 
determined  by  the  user,  the  normal  level  of  resolution  is  battal ion- level  for 
the  blue  force  and  regimental- level  for  the  red  force.  All  ground  elements 
that  are  considered  individual  units  are  located  by  either  a  two-dimensional 
coordinate  or  military  UTM  system.  All  independent  ground  elements  initially 
move  along  assigned  paths  that  represent  avenues  of  approach  or  defensive 
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B-8 


VIC  TERRAIN  FACTORS* 


Vegetation 


1. 

Dense  forestation 

3. 

Grasslands 

2. 

Light  vegetation 

4. 

Urban  areas 

Relief 

1. 

Plains 

3. 

Mountains 

2. 

Hills 

Area 

Obstacles** 

1. 

Rivers 

4. 

Urban  areas 

2. 

Passable  features 

5. 

NBC  contaminated  areas 

3. 

Impassable  features 

Linear  Obstacles 

1. 

Rivers 

3. 

Tank  ditches 

2. 

Canals 

4. 

Embankments  (railway) 

The  number  of  categories  implemented  under  each  terrain  factor  is  user- 
dependent  . 

This  terrain  factor  is  not  used  in  the  current  release  of  VIC. 


Figure  B-2 

zones.  Second  echelon  or  reserve  units  may  change  paths  due  to  changes  in  the 
combat  situation.  Although  the  combined  trafficability  index  has  only  three 
categories  for  each  grid  square,  routes  in  VIC  are  developed  from  detailed  map 
analysis  and  computer  graphics  displays  of  the  terrain.  For  each  node  on  each 
unit's  path,  there  is  an  area  defined  that  represents  the  area  of  influence  or 
interest.  This  tactical  area  defines  the  portion  of  the  battle  area  in  which 
sensors  assigned  to  the  unit  search  for  detections  and  the  area  from  which 
targets  are  selected  for  supporting  indirect  fire  systems. 

9.  Functional  Processes  Modeled.  Figure  B-4  identifies  the  roles  and 
activities  that  maneuver  units  may  play  in  the  model.  VIC  is  structured  in  28 
modules.  Generally,  each  module  maps  into  a  major  functional  process  on  the 
battlefield.  Figure  B-5  identifies  the  individual  modules  and  the  functional 
processes  modeled  in  VIC.  The  modeling  of  the  operations  plan  is  implied 
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VIC  UNIT  TYPES  AND  LEVELS 


Unit  Types 


Tank  unit 
Mechanized  unit 
Infantry  unit 
Cavalry  unit 
Attack  helicopter  unit 
Utility  helicopter  unit 
Cargo  helicopter  unit 
Aviation  HQ  unit 
Artillery  HQ  unit 
Tube  artillery  unit 
Rocket  artillery  unit 


Missile  artillery  unit 
Air  defense  unit 
Headquarters  unit 
Supply  convoy  unit 
Forward  supply  area  unit 
Repair  unit 
Airborne  unit 
Engineer  unit 
Intelligence  unit 
Jamming  unit 

Electronic  helicopter  unit 


Unit  Levels 


Front 

Army 

Corps 

Division 

Regiment 

Brigade 

Battalion 


Task  force 

Company 

Squadron 

Troop 

Battery 

Platoon 


Figure  B-3 

MANEUVER  UNIT  ROLES  AND  ACTIVITIES 


Maneuver  Unit  Roles 


Covering  force 
Main  battle  area 
Reserve 

Rear  area  security 


Deep  strike  (airmobile) 
First  echelon 
Second  echelon 


Defend 

Delay 

Withdraw 

Attack 


Maneuver  Unit  Activities 

Pass  through  lines 
Reorganize 
Permanently  retire 
Bypass 


Counter  -  attack 

Advance 

Pursue 

Move  to  reinforce 


Figure  B-4 
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VIC  MODULES  AND  FUNCTIONAL  PROCESSES 


VIC  MODULES  (with  abbreviation) 


System  Specifications  (SS) 
^Global  Ground  (GG) 
xGround  Movement  (GM) 
Artillery  (AT) 

Global  Air  (GA) 

Air  Maintenance  (AM) 

Air- to-Ground  Attack  (AG) 
Air  Intelligence  (AI) 
Ground  Intelligence  (GI) 
Fusion  Intelligence  (FI) 
Air  Defense  (AD) 

Defense  Suppression  (DS) 
Electronic  Warfare  (EW) 
Chemical  (CH) 


Graphics  Data  Module  (GX) 

Weather  Data  (WT) 

^Terrain  and  Barriers  (TB) 

^Decision  Tables  (DT) 

Helicopters  (HC) 

^Logistics  (LO) 

Communications  (CO) 

^Return- to-Duty  (RD) 

Postprocessor  (PT) 

^Minefields  (MF) 

Air-to-Air  (AA) 

*Front  Line  Detailed  Attrition  (FL) 
Smoke  (SM) 

^Engineer  (EN) 


VIC  FUNCTIONS 


Command  and  control 
Information  processing 
Intelligence  and  fusion  processing 
Electronic  warfare 
Maneuver-unit  combat 
Engineer  operations 


Smoke  operations 
Support-fire  operations 
Attack-helicopter  operations 
Fixed-wing  air  operations 
Air-defense  operations 
Combat  service  support 


x  VIC  modules  that  are  of  particular  interest  for  engineer  representation. 


Figure  B-5 


through  the  force  organization,  missions  assigned  to  each  unit,  and  the  paths 
that  represent  the  unit  areas  for  movement  and  control.  The  following 
paragraphs  briefly  describe  the  purpose  of  the  modules  which  influence  the 
engineer  representation  in  VIC. 

a.  The  Terrain  and  Barriers  Module  provides  the  ability  to  simulate 
the  impact  of  terrain  and  barriers  (other  than  minefields)  on  combat  forces. 
The  key  factors  required  for  this  module  are  vegetation,  relief,  and  linear 
obstacles  (e.g.,  rivers,  embankments,  canals,  antitank  ditches).  These 
factors  effect  movement  and  visibility  of  maneuver  units  as  they  progress 
through  the  campaign  area. 
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b.  The  Global  Ground  Module  is  one  of  the  cornerstones  of  the  VIC 
Model.  This  module  provides  the  necessary  data  that  defines  the  characteris¬ 
tics  of  all  ground  units,  their  initial  locations,  their  initial  maneuver 
plans,  the  size  of  deployment,  and  many  other  parameters  which  are  necessary 
to  define  the  land  scenario.  Many  other  modules  tie  in  with  this  module. 

c.  The  Ground  Movement  Module  provides  input  data  for  ground 
movement,  the  command  structure,  and  the  areas  of  influence  for  those  units 
which  require  them. 

d.  The  Minefield  Module  represents  the  effects  of  minefield 
barriers  in  a  land  campaign.  Other  barrier  types  are  addressed  in  the  Terrain 
and  Barriers  Module.  Minefields  cause  attrition  and  delay  and  limit  movement. 

e.  The  Engineer  Module  represents  the  various  engineer-related 
activities  that  occur  during  a  land  campaign.  VIC  represents  engineer  tasks 
of  divisional  engineer  units  and  higher  echelon  engineer  units. 

f.  The  Front  Line  Detailed  Attrition  Module  handles  the  interac¬ 
tions  of  opposing  front-line  forces  in  a  combat  arena.  The  major  conditions 
addressed  in  the  module  include  unit  combat  roles  and  activities,  the  forces 
involved  (personnel  and  weapon  systems),  environmental  conditions  (terrain, 
weather,  and  minefields),  combat  tactics,  target  acquisition  and  selection, 
and  firepower  and  ammunition  expenditure. 

g.  The  Decision  Table  Module  exercises  control  in  the  automated 
simulation.  The  method  used  in  decision  tables  is  a  process  of  checking 
combinations  of  state  variables  at  fixed  or  variable  periods  of  time  to 
determine  a  course  of  action.  Generally,  there  are  tables  for  each  echelon 
and  for  every  event  that  may  be  encountered  by  a  maneuver  unit  during  the 
campaign.  Units  cjutinue  to  perform  an  activity  until  the  decision  table  for 
that  activity  and  unit  level  direct  them  to  another  activity.  Decision  tables 
consist  of  three  basic  ingredients:  a  set  of  conditions,  a  set  of  situations, 
and  a  set  of  actions.  Whenever  a  decision  table  is  accessed  in  VIC,  the 
following  sequence  of  actions  takes  place: 

Each  condition  specified  in  a  table  is  checked 
to  see  if  it  applies.  This  defines  the  current 
situation. 
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The  set  of  conditions  specified  in  the 
table  are  compared  one-by-one  to  the 
current  situation. 

When  the  first  match  is  found,  if  any, 
then  the  set  of  actions  related  to  the 
matched  situation  are  performed. 

In  some  decision  tables,  one  of  the  specified  actions  may  be  to  continue 
scanning  the  table.  Also,  one  of  the  actions  may  be  to  consult  another 
decision  table  if  the  specified  action  requires  consideration  by  a  higher 
echelon.  The  model  has  a  library  for  "conditions"  and  "actions"  as  well  as  a 
library  for  the  array  of  decision  tables. 

h.  The  Logistics  Module  and  the  Return- to -Duty  Module  represent  the 
supply  and  support  role  of  combat  service  support  (CSS)  with  respect  to 
ammunition,  POL,  subsistence  or  man- consumable  supplies,  maintenance  support, 
field  services,  and  personnel  replacement. 

10.  Model  Results  (Output) .  The  outcome  of  these  force  interactions  is 
measured  in  terms  of  the  ground  gained  or  lost  and  the  attrition  of  personnel 
and  weapon  systems.  VIC  uses  postprocessors  to  describe  the  results  of  the 
simulation. 
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III.  ANALYSIS  OF  ENGINEER  REPRESENTATION 


11 .  General . 

a.  Engineer  units. 

(1)  Engineer  units  of  any  size  can  be  gamed.  Like  other  units 
which  can  independently  maneuver  on  the  ground,  engineer  units  are  identified 
in  the  Global  Ground  Module.  Data  regarding  their  work  accomplishment  rates 
and  capabilities  are  supplied  in  the  Engineer  Module,  and  data  regarding  their 
detailed  composition  and  equipment  are  provided  in  the  Front  Line  Detailed 
Attrition  Module. 

(2)  Only  the  lowest  level  engineer  unit  defined  to  VIC,  usually 
modeled  as  a  platoon,  is  actually  able  to  perform  engineering  tasks.  Units 
representing  higher  echelons  are  also  modeled.  Such  a  unit  can  be  superior  to 
any  number  of  lower  echelon  units.  The  only  purposes  for  superior  level  units 
are  to  arrange  for  reconstitution  (personnel,  equipment,  and  mines)  of  their 
lower  level  units,  assign  them  missions,  and  control  their  movement. 

(3)  In  VIC,  when  a  superior  level  engineer  unit  moves,  the 
lower  level  units  must  also  move  in  such  a  way  that  their  offset  (while  not 
performing  a  mission)  from  the  superior  is  maintained.  If  a  lower  level  unit 
is  performing  a  mission  consisting  of  several  tasks  at  different  locations  at 
the  time  of  the  move,  it  completes  work  on  all  tasks  in  the  mission  prior  to 
moving.  VIC  creates  a  path  for  the  movement  of  the  subordinate  engineer 
units.  Unlike  maneuver  units  undergoing  a  "coordinated  group  move,"  engineer 
units  are  subject  to  the  effects  of  terrain  and  barriers  as  they  move. 

b.  Engineer  unit  capabilities.  Figure  B-6  provides  an  overview  of 
the  engineer  tasks  modeled  in  VIC,  whether  gamed  as  a  capability  of  the 
engineer  unit,  individual  non-engineer  units,  or  both.  Engineer  units  at  the 
lowest  level  (the  only  units  which  can  do  work)  must  be  one  of  four  types. 

Each  type  can  accomplish  only  one  type  of  work.  The  four  unit  types  are 
minefield  teams  (emplacement  only),  linear  obstacle  teams  (emplacement  only), 
bridging  teams,  and  survivability  teams  (defensive  position  construction). 
Subsequent  paragraphs  provide  mere  detail  on  how  VIC  models  these  tasks. 

c.  Engineer  task  assignment  and  ranking. 

(1)  Tasks  for  engineer  units  can  be  specified  in  the  VIC 
model's  input  data.  In  the  Minefield  Module  and  the  Terrain  and  Barriers 
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VIC  ENGINEER  TASKS1 


_ Capability  of: _ 

Non-engineer  Engineer 

Functional  Area _ Task _ Results _ Unit? _ Unit? 


Counte  rmob i I i ty : 


Install  minefields^ 

Enemy  delay, 
attrition 

Yes^ 

Yes 

Install  linear 
obs  taoj.es 

Enemy  delay 

No 

Yes 

Mobility: 

Breach  minefields 

Friendly  delay, 
reduced  attrition, 
improved  mobility 

Yes 

No4 

Breach  linear 
obstacles 

Friendly  delay, 
improved  mobility 

Yes 

No4 

Breach  linear 
obstacles  with 
bridging 

Friendly  delay, 
improved  mobility 

No 

Yes 

Survivability: 

Prepare  defensive 
positions 

Reduced  friendly 
attrition 

Yes 

Yes 

1All  tasks 

take  time  to  perform. 

An  engineer  unit  performing  a 

task  is 

unavailable  for  simultaneous  work  elsewhere.  Engineer  equipment  is  not 
explicitly  modeled. 

^If  the  Logistics  Module  is  played,  this  task  can  explicitly  require  the 
availability  of  mines. 

Artillery  can  emplace  a  minefield  using  FASCAM  munitions. 

^Engineer  unit  capability  is  identical  to  that  of  non-engineer  units. 
Engineer  units  cannot  be  tasked  to  perform  this  mission. 


Figure  B-6 
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Module,  input  data  can  specify  a  site  where  a  minefield  or  linear  obstacle  is 
to  be  emplaced  at  some  future  time.  This  task  is  placed  in  the  engineer  task 
list  by  task  type  and  force  (Red  or  Blue)  and  becomes  an  active  request  when  a 
defending  maneuver  unit  supported  by  an  engineer  unit  is  within  a  user- 
specified  range  of  the  FEBA. 

(2)  When  the  task  is  accomplished  depends  on  resource  availa¬ 
bility  (engineer  units  and,  if  logistics  is  played,  mine  availability).  The 
model  user,  via  input  data,  controls  how  tasks  are  grouped  into  missions  based 
on  geographic  location  of  the  task  site  (offset  from  the  FEBA  and  tactical 
area)  and  unit  munitions -carrying  capability.  Whenever  possible,  the  engineer 
units  are  to  accomplish  all  tasks  in  the  mission  before  returning  to  their 
base  for  resupply,  movement,  and  subsequent  tasking. 

(3)  Once  requests  for  emplacement  of  a  minefield  or  linear 
obstacle  become  active,  they  are  ranked  by  proximity  to  the  FEBA.  A  minimum 
and  maximum  offset  must  exist  before  engineers  will  attempt  the  task.  Within 
that  user-specified  range  of  distance  from  the  FEBA,  tasks  closest  to  the  FEBA 
will  be  attempted  first.  If,  during  task  work,  the  FEBA  trace  moves  to  a 
distance  less  than  the  minimum  offset,  the  engineer  unit  will  stop  work  on  the 
task  and  abort  the  current  mission.  A  minefield  that  is  partially  completed 
is  ineffective;  the  effectiveness  of  a  partially-completed  linear  obstacle  is 
proportional  to  the  time  spent  constructing  the  obstacle  before  aborting  the 
mission . 

(4)  Survivability  position  construction  tasks  are  scheduled  in 
much  the  same  way  as  minefield  and  linear  obstacle  emplacement  tasks  except 
that  the  input  data  does  not  permit  a  time  at  which  the  sites  are  to  be 
prepared.  Thus,  task  generation  is  more  dynamic.  The  various  path  points 
through  which  a  maneuver  unit  passes  are  designated  in  the  input  data  as 
either  needing  or  not  needing  preparation.  The  proximity  to  the  FEBA  dictates 
task  priorities . 

(5)  Engineer  bridge  team  assistance  is  requested  dynamically  by 
a  maneuver  unit  when  they  encounter  a  river  or  other  linear  obstacle  which  has 
been  specified  by  input  data  in  the  Terrain  and  Barriers  Module  as  requiring  a 
breach  with  bridging.  Engineer  breaching  support  is  performed  in  the  order 
requested. 
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d.  Task  accomplishment. 

(1)  Task  accomplishment  consists  of  several  processes,  each 
requiring  time.  These  include  return  to  engineer  base  (i.e.,  to  the  next 
superior- level  unit)  and  replenish,  move  as  a  result  of  superior  engineer  unit 
move,  receive  next  mission  (actually  a  set  of  tasks),  travel  to  first  task 
site,  set  up,  perform  task,  travel  to  next  t .  "k  site,  etc.  During  any  of 
these  processes,  the  engineer  units  can  be  delayed  and  constrained  by  artil¬ 
lery  and  air  activity,  munitions  availability,  user-specified  work  accomplish¬ 
ment  rates,  and  the  length  of  time  they  can  work  without  an  enforced  rest 
period . 

(2)  Although  VIC  is  capable  of  attrition,  engineers  have 
typically  not  suffered  from  these  effects  in  past  studies.  Engineer  attrition 
in  VIC  involves  three  elements.  First,  engineer  units  must  be  classified  as 
opponents  which  interact  with  opposing  forces.  Second,  "engineer  systems" 
must  be  classified  as  targets  for  attack.  Third,  direct-fire  attrition  can 
occur  only  if  the  minimum  FEBA  offset  for  engineer  units  performing  tasks  is 
set  to  less  than  the  range  of  direct  fire  weapons. 

12.  Countermob ili tv. 

a.  General.  VIC  models  engineer  unit  operations  of  emplacing 
minefields  and  constructing  linear  obstacles.  VIC  does  not  model  point 
obstacles;  however,  VIC's  method  of  treating  linear  obstacles  makes  it 
possible  to  attain  a  degree  of  point  obstacle  representation  by  modeling  it  as 
a  short  linear  obstacle.  VIC  does  not  model  main  supply  route  (MSR)  interdic¬ 
tion  techniques,  such  as  bridge  demolition,  but  it  does  model  the  destruction 
of  tactical  bridges  by  friendly  units  in  retrograde.  This  latter  task  is 
implicitly  modeled;  there  is  no  time  penalty  associated  with  "undoing"  the 
breach . 

b.  Minefields.  VIC  provides  flexibility  to  the  model  user  in 
minefield  specification,  emplacement  means,  and  activation.  Figure  B-7  lists 
the  major  minefield  characteristics  that  VIC  supports. 

(1)  Minefields  can  be  any  of  several  user- specif ied  generic 
types,  each  with  its  own  characteristics  of  lethality  to  various  weapon 
prototypes,  delay  due  to  discovery,  breach,  negotiation,  and  minefield 
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MINEFIELDS  IN  VIC 


Minefield  Types : 

Anti-armor,  Anti-personnel,  or  both. 

Directed,  conventional,  or  scatterable. 

Emplacement  Options: 

Pre-existing:  Minefield  locations  can  exist  at  the  beginning  of  the 
simulation.  Mines  for  these  minefields  can  be  already  emplaced  and  active,  or 
they  can  be  emplaced  and  "fuzed"  to  become  active  at  a  specified  later  time. 
For  both  of  these  cases,  it  is  possible  to  specify  a  "defuze"  time  when  the 
minefield  is  deactivated. 

Engineer  unit  emplacements:  It  is  also  possible  to  specify  a  location 
as  a  potential  minefield  site  which  can  be  automatically  selected  for  mine¬ 
field  emplacement  by  an  engineer  minefield  team  when  certain  conditions  (in 
Decision  Tables)  are  met.  It  is  also  possible  to  construct  an  engineer 
mission  to  install  the  minefield  through  the  Decision  Table  logic.  Engineer 
unit  equipment,  such  as  a  GEMSS  dispenser,  is  not  explicitly  modeled. 

However,  the  Engineer  Module  can  specify  implicitly  manual  or  equipment- 
assisted  dispensing  through  input  data. 

Artillery-delivered  emplacements:  It  is  possible  for  a  maneuver  unit  to 
dynamically  request  a  FASCAM  minefield  from  an  artillery  unit  as  a  result  of  a 
tactical  decision  rule.  VIC  determines  the  location  and  all  other  attributes 
for  this  minefield. 

Physical  Attributes: 

The  following  minefield  characteristics  can  be  specified  in  the  Mine¬ 
field  Module:  number  of  mines,  minefield  frontage,  minefield  depth, 
orientation  (degrees),  UTM  coordinates  of  the  minefield  center,  and  several 
attributes  that  determine  the  outcome  when  a  maneuver  unit  encounters  the 
minefield. 


Figure  B-7 
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clearing  fraction  associated  with  crossing  tactic.  It  is  possible  to  overlay 
multiple  minefield  types.* 

(2)  The  input  data  for  the  Minefield  Module  also  contains  the 
minefield  mission  numbers  that  control  which  minefield  laying  tasks  will  be 
grouped  into  a  minefield  team  mission.  The  order  in  which  the  missions  are 
selected  is  a  function  of  distance  from  the  FEBA. 

(3)  If  the  FEBA  moves  in  such  a  way  that  engineer  units  are 
threatened  (the  distance  decreases  to  the  minimum  offset  value  specified  in 
the  input  data) ,  the  unit  will  stop  working  on  the  current  task  and  abort  the 
mission.  In  this  case,  the  minefields  that  were  totally  completed  on  the 
mission  would  be  effective;  the  partially-  and  to -be  -  completed  minefields  in 
the  mission  would  be  ineffective. 

(4)  Only  an  engineer  minefield  team  (and  artillery  units  firing 
FASCAM  munitions)  may  be  tasked  to  emplace  a  minefield.  To  perform  the 
engineer  mission,  VIC  logic  selects  the  first  available  team  that  is  support¬ 
ing  the  unit  (tactical  area). 

(5)  Artillery-delivered  FASCAM  may  be  requested  by  maneuver 
units  in  areas  where  minefields  were  not  preplanned. 

c.  Linear  obstacles. 

(1)  Linear  obstacles  (e.g.,  rivers,  embankments,  canals, 
antitank  ditches)  are  defined  by  VIC  in  the  Terrain  and  Barriers  Module.  They 
can  be  initially  active  or  inactive.  If  inactive,  they  can  be  activated  later 
by  an  engineer  linear  obstacle  team.  Linear  obstacles  are  composed  of  a  user- 
specified  number  of  line  segments.  Each  segment  of  the  obstacle  can  have 
unique  delaying  characteristics  assigned  by  the  user.  There  is  no  current  way 
to  assign  attrition  characteristics  to  linear  obstacles.  However,  combat 
multiplier  effects  are  represented  because  of  the  greater  attrition  that 
occurs  from  covering  fire  as  the  unit  is  delayed  while  breaching  the  obstacle. 


*While  it  is  possible  to  overlay  multiple  minefield  types,  it  is  impor¬ 
tant  to  note  that  overlaying  minefields  does  not  necessarily  provide  combined 
effects  for  units  encountering  these  minefields.  VIC  processes  a  single 
minefield  at  a  time  and  physically  "jumps"  a  unit  over  a  minefield  after  the 
proper  delay  has  been  assessed.  If  a  second  minefield  is  totally  contained  in 
the  first,  or  has  its  center  within  the  first,  the  unit  will  not  encounter  the 
second  minefield  because  of  the  jump. 
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(2)  Obstacles  are  encountered  by  any  maneuver  unit  traversing  a 
path  that  crosses  an  obstacle  line  segment.  The  obstacle  line  segments 
themselves  are  defined  with  starting  and  ending  coordinates.  The  length  of 
these  line  segments  is  independent  of  the  VIC  grid  square  terrain  representa¬ 
tion.  It  is  possible  to  specify  that  one  or  more  of  the  line  segments 
composing  the  linear  obstacle  are  already  breached  at  the  start  of  model  play. 

(3)  Delay  times  due  to  barrier  encounters  can  be  separately 
specified  for  breached  and  unbreached  conditions  and  for  the  force  (Red  or 
Blue)  encountering  the  obstacle.  Input  data  can  also  specify  whether  any 
particular  obstacle  line  segment  requires  bridging  in  order  to  be  breached,  or 
whether  it  has  already  been  breached. 

(4)  Engineer  team  emplacement  of  a  linear  obstacle  is 
accomplished  in  a  manner  similar  to  the  emplacement  of  a  minefield.  The 
mission  numbers  are  contained  in  the  Terrain  and  Barriers  Module. 

13 .  Mobility. 

a.  Engineer  unit  mobility  tasks. 

(1)  The  only  VIC  engineer  unit  capable  of  performing  a  mobility 
task  is  the  bridge  team.  This  capability  can  be  used  to  cross  a  river  or 
other  linear  obst  cle,  such  as  a  dry  gap.  Bridge  equipment  is  not  explicitly 
modeled . 

(2)  Other  mobility  functions  played  in  VIC  are  implicitly  the 
responsibility  of  maneuver  units.  Even  bridging  operations  can  be  implicitly 
performed  by  a  maneuver  unit  when  engineer  assistance  is  unavailable. 

(3)  VIC  does  not  currently  model  engineer  mobility  tasks 
related  to  the  construction,  maintenance,  and  repair  of  MSRs .  Rear  area  MSRs 
are  explicitly  introduced  into  the  model  in  the  Logistics  Module  and  are  used 
only  for  the  transport  of  supplies  and  damaged/repaired  equipment  --  not  for 
maneuver  unit  operations.  While  attrition  of  logistics  units  conducting 
resupply  operations  along  an  MSR  is  played,  degradation  and  interdiction  of 
the  MSR  itself  is  not  modeled. 

(4)  VIC  also  does  not  play  breaching  of  survivability  or 
heavily  fortified  positions.  VIC  does  not  model  a  breach  of  a  point  obstacle, 
and  it  does  not  generate  requirements  for  pioneer  trail  construction  main¬ 
tenance,  or  repair. 
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b.  Effects  of  minefields  on  maneuver  unit  operations. 

(1)  A  maneuver  unit  will  encounter  a  minefield  whenever  its 
straight  line  traverse  between  two  path  points  intersects  an  active  minefield. 
The  minefield's  location  is  not  bound  by  the  terrain  grid  square  limitations. 
When  a  maneuver  unit  encounters  a  minefield,  the  input  data  for  the  minefield 
is  referenced  to  see  what  type  of  minefield  it  is.  If  it  is  a  "directed 
minefield,"  then  attrition  and  delay  amounts  are  immediately  applied  and  the 
minefield  is  considered  cleared  and  removed  from  the  list  of  active 
minefields . 

(2)  If  a  conventional  or  scatterable  minefield  that  has  not 
been  previously  discovered  is  encountered,  then  attrition  and  delay  are 
applied  according  to  constants  supplied  in  the  input  data.  This  is  called  a 
"discovery"  loss.  Next,  an  additional  delay  is  assessed  representing  the  time 
it  takes  for  the  unit  commander  to  decide  the  minefield  tactic  to  be  employed 
(breach,  bull,  or  bypass). 

(a)  The  breach  option  is  modeled  to  represent  a  deliberate 
breach.  There  are  attrition  and  delay  effects  associated  with  this  tactic. 

The  deliberate  breach  is  implicitly  assumed  to  be  accomplished  with  organic 
resources,  but  any  breaching  equipment  actually  available  to  the  unit  does  not 
enter  into  the  calculation  of  breach  time.  The  breach  time  is  a  function  of 
the  type  of  minefield,  and  its  density,  frontage,  and  depth. 

(b)  The  bull  option  is  modeled  as  a  hasty  breach  with 
attendant  increased  attrition  and  reduced  delay  effects  as  compared  with  the 
deliberate  breach. 

(c)  The  bypass  option  consists  of  a  delay  with  no  attri¬ 
tion  except  for  that  resulting  from  fires  the  unit  may  already  be  receiving. 

At  the  end  of  the  delay  period,  the  unit  is  relocated  to  the  other  side  of  the 
minefield.  This  method  of  processing  enables  a  bypass  tactic  selection  even 
when  a  bypass  route  is  actually  not  available. 

(d)  The  specific  tactic  to  be  employed  is  selected  through 
the  Ground  Combat  Status  Mapping  Table  in  the  Global  Ground  Module.  The 
selection  is  based  only  on  the  combat  status  of  the  unit. 

(3)  The  next  effect  of  the  minefield  is  an  attrition  and  delay 
associated  with  actual  negotiation  of  the  minefield  (for  breach  and  bull 
tactics  only) .  The  delay  and  attrition  factors  are  controlled  by  the  model 
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user  via  the  input  data.  Attrition  effects  can  be  specified  to  weapon 
prototype  detail,  if  desired.  The  negotiation  attrition  is  assessed  at  the 
end  of  the  negotiation  delay  period.  The  timing  of  the  minefield  attrition  is 
significant.  The  net  effect  is  that  while  the  unit  is  engaged  in  combat  and 
simultaneously  negotiating  the  minefield,  they  are  fighting  at  a  strength 
which  does  not  take  into  account  the  attrition  effects  of  the  minefield. 

(4)  The  combat-multiplier  effect  of  a  minefield  is  modeled  by 
the  additional  delay  imposed  on  the  unit  as  it  negotiates  the  minefield.  This 
increases  the  unit's  losses  from  direct/indirect  fire  as  it  enters  the 
minefield.  There  are  no  routines  currently  implemented  via  decision  tables 
that  create  a  request  for  indirect  fire  upon  an  enemy  unit  detected  entering  a 
minefield. 

(5)  For  minefields  that  hsvp  been  previously  discovered  there 
are  two  primary  differences  from  the  description  provided  in  paragraphs  (1) 
through  (4)  above.  First,  there  is  no  delay  and  attrition  assessed  as  a 
discovery  loss.  Second,  prior  breach  and/or  bull  activity  has  reduced  the 
minefield  effectiveness  by  prescribed  amounts.  Attrition  and  delay  effects 
are  linearly  dependent  on  the  fraction  of  remaining  minefield  effectiveness. 
After  the  minefield  effectiveness  is  reduced  to  an  input- data-prescribed 
fraction  of  its  original  value,  the  minefield  is  considered  to  be  totally 
ineffective  and  is  removed  from  the  list  of  active  minefields. 

(6)  Another  factor  affecting  unit  attrition  from  a  minefield  is 
the  combat  status  (i.e.,  engaged  or  not  engaged  in  combat)  of  the  unit  as  it 
enters  the  minefield.  VIC  normally  models  units  as  being  deployed  in  a  circle 
with  equipment  and  personnel  deployed  within  that  circle  Into  the  front,  rear, 
and  flanks.  However,  when  a  manuever  unit  encounters  a  minefield,  VIC  also 
looks  at  the  unit  deployment  in  terms  of  columns.  The  unit  formation  (con¬ 
trolled  by  input  data)  will  normally  spread  out  and  use  more  columns  if  the 
unit  is  engaged.  Thus,  if  the  minefield  frontage  is  less  than  the  width  of 
the  deployed  unit,  then  the  fraction  of  the  unit  entering  the  minefield  will 
be  smaller  when  the  unit  is  engaged. 

c.  Effects  of  linear  obstacles  on  maneuver  unit  operations. 

(1)  Like  minefields,  a  maneuver  unit  will  encounter  a  linear 
obstacle  whenever  its  straight  line  traverse  between  two  path  points  inter¬ 
sects  an  active  obstacle.  Units  cannot  bypass  a  linear  obstacle  in  VIC, 
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hov/ever.  When  a  maneuver  unit  encounters  a  linear  obstacle,  they  are  delayed 
a  set  amount  of  time.  This  time  is  dependent  on  whether  the  obstacle  has 
already  been  breached  and  whether  the  side  encountering  the  obstacle  is  Red  or 
Blue.  The  actual  delay  constants  are  specified  in  the  input  data  for  each 
individual  generic  linear  obstacle.  As  many  generic  types  as  desired  may  be 
input.  The  maneuver  unit  conducts  the  breach  using  resources  implicitly 
assumed  to  be  available. 

(2)  If  the  obstacle  is  a  river  or  a  gap  that  requires  a  bridge 
for  breaching,  then  the  maneuver  unit's  actions  are  different.  Upon 
encountering  such  an  obstacle,  the  maneuver  unit  will  immediately  request 
assistance  from  an  engineer  bridge  team.  In  the  meantime,  it  "begins"  work  to 
breach  the  obstacle  itself.  It  does  not  need  to  have  a  bridge  to  do  this 
work;  it  simply  requires  the  amount  of  time  specified  in  the  input  data  of  the 
Terrain  and  Barriers  Module.  If  the  engineer  unit  never  arrives,  it  is  still 
possible  for  che  maneuver  unit  to  complete  the  breach.  If  the  engineer  unit 
arrives,  the  breach  time  is  reduced  by  taking  into  account  the  work  the 
maneuver  unit  had  already  completed. 

(3)  At  present,  if  a  maneuver  unit  encounters  one  of  the  line 
segments  composing  a  linear  obstacle,  it  is  not  possible  in  VIC  for  the  unit 
to  determine  if  a  nearby  line  segment  composing  the  total  obstacle  has  already 
been  breached.  It  may,  in  reality,  be  more  expedient  for  the  unit  to  bypass 
the  obstacle  using  a  breach  already  created.  Also,  VIC  does  not  currently 
model  the  creation  of  several  breach  positions  (multiple  bridges)  on  the  same 
obstacle  line  segment. 

14 .  Survivability . 

a.  Armor  and  infantry  survivability  positions. 

(1)  VIC  models  the  use  of  engineer  teams  to  construct  sur¬ 
vivability  positions.  All  path  points  requiring  preparation  of  positions  are 
specified  in  input  data.  These  data  associate  a  prepared/unprepared  condition 
(ranging  in  value  from  1.0  to  0.0)  with  these  path  points.  This  condition  is 
used  to  modify  loss  rates  in  direct  fire  exchanges  and  to  modify  th”  portion 
of  the  unit  exposed  to  air  and  artillery  barrages.  The  kill  rates  used  in  VIC 

~k 

The  input  data  that  portrays  the  linear  obstacle  controls  the  time  for  a 
manuever-unit  breach.  If  maneuver  units  are  incapable  of  breaching  the 
obstacle,  its  unassisted  breach  time  should  be  set  to  a  large  number  (infinity). 


assume  that  some  advantage  of  natural  cover  has  been  taken  even  for  unprepared 
positions . 

(2)  Engineer  survivability  teams  simply  work  on  the  path  point 
requiring  positions  in  the  tactical  area  which  is  closest  (but  not  too  close) 
to  the  FEBA.  Therefore,  it  is  possible  that  a  point  which  is  closest  to  the 
FEBA,  but  has  no  unit  moving  to  it,  is  prepared  before  a  path  point  which  is 
further  irom  the  FEBA  and  has  unit  moving  to  it  for  cover. 

(3)  Manuever  units  also  have  a  user- specif ied  capability  to 
prepare  positions  for  themselves.  The  time  to  complete  that  activity  can  be 
input  for  each  maneuver  unit  prototype  defined  to  VIC.  Whether  preparation  is 
performed  by  engineers  or  the  maneuver  unit  itself,  a  partially  completed  job 
provides  partially  improved  protection. 

b.  Artillery  and  rear  area  survivability  positions.  Artillery 
units  and  units  in  the  corps  rear  areas  do  not  currently  have  the  capability 
to  request  engineer  unit  assistance  for  preparing  defensive  or  protective 
positions . 

15.  Sustainment  Engineering.  VIC  does  not  presently  model  any  sustain¬ 
ment  engineering  tasks. 

16.  Topographic  Engineering  and  Fighting  as  Infantry.  VIC  does  not 
currently  model  any  of  the  engineer  tasks  associated  with  topographic  support 
and  engineers  fighting  as  infantry. 
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IV.  COMPARISON  WITH  DESIRED  LEVEL  OF  ENGINEER  REPRESENTATION 


17.  Desired  Level  of  Engineer  Representation.  The  level  of  engineer 
representation  in  VIC  should  depend  on  the  model  purpose  (the  types  of  studies 
the  model  supports),  and  the  needs  of  the  analytic  community.  This  represen¬ 
tation  must  have  an  impact  on  the  other  functions  modeled  in  VIC,  and  it 
should  also  maintain  a  balanced  representation  with  them. 

a.  VIC  purpose  and  use.  VIC's  purpose  is  to  simulate  a  mid¬ 
intensity  battle  of  opposing  forces  up  to  a  US  Army  corps  in  order  to  analyti¬ 
cally  estimate  net  assessments,  perform  force  deployment  studies,  or  generate 
information  for  performing  trade-offs  among  weapon  systems.  TRAC  is  the 
primary  user  of  the  VIC  model.  Figure  B-8  describes  the  purposes  of  TRAC 
studies  that  have  been  conducted  using  VIC.  According  to  the  AMIP  Management 
Office,  there  are  over  100  potential  studies  that  could  be  conducted  using 
VIC,  but  only  a  few  of  these  studies  are  assigned  a  TRADOC  priority  high 
enough  to  be  conducted  on  VIC  by  TRAC  each  year.  Engineer-specific  studies  do 
not  have  a  priority  high  enough  to  be  conducted  by  TRAC  using  VIC.-’  There¬ 
fore,  the  engineer  representation  in  VIC  should  have,  as  a  minimum,  sufficient 
detail  and  fidelity  to  ensure  that  model  results  are  reasonable  and  adequate 
for  the  specific  VIC  applications  (primarily  non-engineer  studies) . 

b.  Desired  engineer  representation  in  VIC.  Because  VIC  is  the 
Army's  mid- resolution ,  corps/division  simulation  model,  this  model  should,  as 
a  minimum,  represent  the  effects  resulting  from  the  execution  (or  non¬ 
execution)  of  engineer  tasks  that  are  performed  forward  of  the  corps  rear 
boundary  (either  explicitly  or  implicitly).  Figure  B-9  identifies  those  tasks 
by  engineer  functional  areas.  Four  engineer  tasks  (rear  area  facilities 
rehabilitation  and  maintenance,  airfield  damage  repair,  port  and  waterfront 
facilities  construction  and  repair,  and  other)  described  in  Annex  F  were  not 
included  in  Figure  B-9  because  the  tasks  are  normally  performed  behind  the 
corps  rear  boundary.  Additionally,  these  four  tasks  are  not  as  important 


-’TRADOC  memorandum  (ATRC-RPP)  ,  Subject:  FY  88  TRADOC  AR  5-5  Study 
Program,  29  October  1987. 

xSee  Annex  F,  "Engineer  Task  Analysis,"  for  more  details  on  the  selection 
ot  engineer  tasks  in  a  mid- resolution  combat  simulation  model. 
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VIC  STUDY  PURPOSES 


Battlefield  90:  A  joint  Gerraan-US,  corps-level  investigation  of  a  Warsaw  Pact 
invasion,  including  the  effects  of  minefield  attrition  on  the  enemy  force. 

Combined  Arms  MAA:  To  investigate  the  relative  importance  of  improving 
various  force  capabilities.  Focus  was  on  combat-heavy  components  and  their 
division/corps  support  functions. 

Armored  Family  of  Vehicles:  To  investigate  the  Army's  litoht,  medium,  and 
heavy  vehicles  used  in  a  stand-alone  or  weapons  platform  mode.  The  three 
cases  were  the  current  vehicle,  upgraded  current  vehicle,  and  new  vehicle 
(with  interchangeable  parts) . 

Forward  Area  Air  Defense  System:  To  examine  the  sensitivity  of  VIC  to  changes 
in  Air  Defense  structures  and  the  contribution  of  air  defense  artillery  to  the 
corps  battle. 

Deep  Fires:  To  investigate  the  mix  and  quantity  of  delivery  vehicles  and 
munitions  that  satisfy  the  Army's  requirements  for  attacking  the  enemy  deep 
under  AirLand  Battle. 

Close  Combat  Capability  Analysis:  To  perform  a  Close  Combat-Heavy  and  Close 
Combat-Light  MAA.  To  determine  the  force  components  with  the  greatest  effect 
on  the  battlefield  and  the  effectiveness  of  improvements  to  the  capabilities 
of  a  given  force  component. 


Figure  B-8 

(tasks  have  a  lower  priority  for  engineer  execution)  as  the  other  tasks  in  a 
corps/division- level  model. 

18 .  Comparison  with  VIC  Model . 

a.  Current  level  of  representation.  Figure  B-10  summarizes  VIC's 
current  representation  of  engineer  tasks.  For  ease  of  comparison  with  VIC, 
linear  obstacles  are  further  separated  into  the  categories  of  minefields, 
other  linear  obstacles,  and  complex  obstacles.  Complex  obstacles  are  combina¬ 
tions  of  minefields  and/or  linear  obstacles.  Engineer-related  tasks  can  be 
performed  by  both  engineer  and  non- engineer  units.  Engineer  unit  capability 
resides  in  four  teams  (minefield,  linear  obstacle,  bridging,  and 
survivability) .  While  VIC  does  account  for  unit-allocated  equipment  and  has 
the  capability  to  attrit  specific  classes  of  equipment,  the  availability  and 
capability  of  that  equipment  does  not  affect  engineer  unit  work  accomplishment 
rates . 
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DESIRED  ENGINEER  TASKS  FOR  VIC 


Countermob  lilt'. 


Install  linear  obstacles  (conventional  and  scatterable  minefields,  other 
linear  obstacles,  complex  obstacles)* 

Install  point  obstacles* 

Mobility 

Breach  obstacles  in  the  assault 

Improve  assault  breaches  for  follow-on  forces 

Conduct  river  crossing  operations  in  the  assault  (tactical  bridging) 

Improve  river  crossing  sites  for  follow-on  forces  (fixed  bridging) 

Prepare  and  maintain  pioneer  trails 

Prepare  and  maintain  forward  airlanding  facilities 

Survivability 

Prepare  fighting  positions  for  direct  fire  systems 
Prepare  positions  for  indirect  fire  and  other  systems 

Sustainment  Engineering 

Maintain  main  supply  routes  (roads) 

Prepare  and  maintain  sites  for  combat  support  (CS)  and  combat  service  support 
(CSS)  units 

Topographic  Engineering  and  Fighting  as  Infantry 


Should  also  allow  synergistic  effect  of  obstacles  with  direct  and 
indirect  fires  (attrition  rates) . 


Figure  B-9 

(1)  Countermobility.  Non-engineer  man°uver  units  (except  for 
artillery)  cannot  perform  countermobility  tasks  with  organic  capability.  The 
two  classes  of  tasks,  minefields  and  linear  obstacles,  are  modeled  strictly  as 
engineer  unit  capabilities.  Pre-planned  minefield  locations  must  be  scripted 
in  the  input  data.  Other  minefields  may  be  dynamically  emplaced  by  artillery 
or  emplaced  by  engineers  through  decision  tables.  Minefield  emplacement  tasks 
are  activated  as  a  function  of  the  location  of  the  maneuver  unit  and 
supporting  engineer  unit,  and  the  minefield  site.  Linear  obstacle  emplacement 
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CURRENT  REPRESENTATION  OF  ENGINEER  TASKS  IN  VIC 


Task 

Capability 

Capability 

Effects 

of 

of 

Modeled? 

Non-eneineer  Unit?-*- 

Ensineer  Unit?-'- 

Countermobility: 


Minefields 

Yes 

No2 

Yes2 

Linear  obstacles 

Yes 

No 

Yes-5 

Point  obstacles 

No 

No 

No 

Complex  obstacles 

No 

No 

No 

Mobility: 

Minefield  breaches 

Yes4 

Implied 

Implied6 

Linear  obstacle  breaches 

Yes4 

Implied 

Implied6 

Complex  obstacle  breaches 

No 

No 

No 

Point  obstacle  breaches 

No 

No 

No 

Improve  assault  breaches 

No 

No 

No 

Assault  river  crossings 

Yes 

Implied 

Yes 

River  crossing  sites 

No 

No 

No 

Pioneer  trails 

No 

No 

No 

Airlanding  facilities 

No 

No 

No 

Survivability: 

Direct  fire  positions 

Yes6 

Explicit 

Yes 

Indirect  fire  positions 

No 

No 

No 

Sustainment  Engineering: 

Main  supply  routes 

No 

No 

No 

CS  and  CSS  sites 

No 

No 

No 

^-Engineer  equipment  is  implicitly  modeled. 

^Artillery  can  emplace  a  minefield  using  FASCAM  munitions. 

2The  execution  of  this  task  can  be  scripted  or  generated  dynamically. 
The  site  for  obstacle  emplacement  must  be  scripted  in  model  input  data. 

4Delay  and/or  attrition  are  functions  of  the  obstacle  and  do  not  depend 
on  capabilities  of  breaching/crossing  units. 

-’Capability  is  identical  to  that  of  non-engineer  units.  Engineer  units 
cannot  be  tasked  to  perform  this  mission. 

^Subsequent  repair  and  improvement  tasks  are  not  modeled. 


Figure  B-10 
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options  in  VIC  are  very  similar  to  the  minefield  options.  VIC  does  not 
explicitly  play  point  obstacles. 

(2)  Mobility.  VIC  models  the  delay  and  attrition  that  is 
associated  with  several  mobility  functions.  However,  in  general,  it  does  not 
model  obstacle  breach  activity  as  an  engineer  unit  capability.  Instead, 
breaching  is  performed  by  the  maneuver  unit  encountering  the  obstacle  --  with 
resources  that  are  implicitly  assumed  as  available.  The  only  exception  is 
that  engineer  assistance  is  requested  when  a  unit  encounters  a  linear  obstacle 
which  must  be  crossed  using  a  bridge.  In  this  case,  however,  input  data  can 
still  specify  a  capability  to  cross  the  gap  even  if  engineer  unit  help  is  not 
immediately  available.  Subsequent  improvements  to  a  breach  of  any  linear 
obstacle  type  (e.g.,  fixed  bridging)  are  not  presently  modeled. 

(3)  Survivability.  The  only  survivability  task  modeled  in  VIC 
is  preparation  of  fighting  positions.  These  positions  currently  must  be 
scripted  in  the  input  data.  Thus,  it  is  not  currently  possible  to  call  for 
preparation  of  positions  at  a  path  point  that  is  dynamically  generated  by  a 
VIC  decision  table.  VIC  can  provide  an  explicit  capability  for  all  modeled 
units  (including  engineer  survivability  teams)  to  perform  this  task. 

b.  Desired  improvements.  The  areas  in  VIC  where  improvement  is 
desired  can  be  derived  by  comparing  the  desired  level  of  engineer  play,  as 
listed  in  Figure  B-9,  and  the  current  level  of  engineer  play,  as  depicted  in 
Figure  B-10.  Figure  B-ll  lists  these  desired  improvements.  The  focus  of 
these  improvements  is  primarily  to  introduce  additional  tasks  that  engineers 
commonly  perform  in  the  corps'  area  of  operation.  In  conjunction  with  the 
addition  of  these  engineer  tasks,  the  tactical  effects  resulting  from  the 
execution  of  these  tasks  certainly  must  be  incorporated  in  VIC.  These 
improvements  are  further  described  in  the  remainder  of  this  paragraph. 

(1)  General. 

(a)  The  model  should  permit  requests  for  engineer  unit 
assistance  for  each  type  of  task  that  engineers  are  expected  to  accomplish  in 
the  corps  area.  Engineers  should  execute  those  tasks  consistent  with  avail¬ 
able  capability  and  resources. 

(b)  All  engineer  units  in  VIC  should  have  the  capacity  to 
perform  each  type  of  engineer  task  in  the  scenario.  This  will  remove  the 
artificial  constraint  that  engineer  units  at  only  the  lowest  level  are  capable 


DESIRED  IMPROVEMENTS  TO  VIC  ENGINEER  REPRESENTATION 


Task 

Code 

InrDrovement 

General : 

G1 

Revise  the  engineer  unit  representation  and 
the  method  of  resource  allocation.  Ensure 
that  combat  engineers  and  equipment  are 
subject  to  the  effects  of  attrition  and  that 
attrition  affects  engineer  task  performance 
capability 

G2 

Ensure  that  engineer  task  performance  of  non¬ 
engineer  units  is  commensurate  with  ability 

G3 

Account  for  effects  of  night,  weather,  smoke, 
and  NBC  on  engineer  task  performance 

G4 

Add  postprocessor  reports  that  capture 
performance  (and  non-performance)  of  all 
engineer  tasks 

G5 

Fully  integrate  combat  engineers  and  their 
equipment  and  materiel  with  the  Logistics 
Module  and  Return- to -Duty  Module 

G6 

Revise  VIC's  coordinated  group  move  logic  so 
that  maneuver  units  will  encounter  terrain 
effects  (including  minefields  and  other 
obstacles)  during  such  moves 

G7 

Add  capability  for  maneuver  units  to  use  roads 

G8 

Add  capability  to  degrade  and  damage  roads  and 
MSRs 

Countermobility : 

Minefields 

CM1 

Add  capability  for  helicopter/aircraft- 
delivered  scatterable  mines 

CM2 

Add  capability  to  close  lanes  in  minefields 

Linear  obstacles 

CM3 

Add  capability  for  dynamic  site  selections  and 
emplacements 

CM4 

Add  capability  to  close  lanes  in  linear 
obstacles 

Complex  obstacles 

CMS 

Add  dynamic  capability  for  engineer  units  to 
emplace  complex  obstacles 

Point  obstacles 

CM6 

Add  capability  for  scripted  and  dynamic  point 
obstacle  emplacements 

CM7 

Allow  synergistic  effects  of  point  obstacles 

Figure  B-ll  (Continued  on  Next  Page) 


DESIRED  IMPROVEMENTS  TO  VIC  ENGINEER  REPRESENTATION 


Continued 


Task 

Code 

Improvement 

Mobility: 

Minefield  breaches 

Ml 

Add  dynamic  capability  for  engineer  units  to 
breach  minefields 

M2 

Add  capability  to  request  breaches  by  engineei 
units,  to  include  requests  from  units  bypass¬ 
ing  minefields 

M3 

Add  more  parameters  for  selecting  the 
appropriate  breaching  tactic  (bypass,  bull, 
breach) 

M4 

Add  capability  for  subsequent  improvement  of 
minefield  breaches  by  engineer  units 

Linear  obstacle 

M5 

Add  dynamic  request  and  capability  for 

breaches 

engineer  units  to  breach  linear  obstacles 

M6 

Add  capability  to  search  for  nearby  paths 
across  obstacles  before  breaching 

M7 

Add  capability  to  create  multiple  breaches  on 
a  single  linear  obstacle  segment 

M8 

Add  capability  for  subsequent  improvements  of 
linear  obstacle  breaches  by  engineer  units 

Complex  obstacle 

M9 

Add  dynamic  capability  for  engineer  units  to 

breaches 

breach  complex  obstacles 

Point  obstacle 

M10 

Add  capability  for  engineer  units  to  breach 

breaches 

point  obstacles 

Mil 

Add  capability  for  non-engineer  units  to 
breach  with  organic  resources  or  request 
engineer  unit  support 

Assault  river 

Ml  2 

Add  capability  to  cross  gaps  by  means  other 

crossings 

than  bridging  (fording,  bypass,  breaching) 

M13 

Ensure  that  gaps  which  require  bridging  cannot 
be  breached  without  bridging 

M14 

Ensure  that  bridge  asset  availability  is 
modeled  exp1 icitly 

River  crossing  sites 

M15 

Add  capability  for  subsequent  improvement  of 
river  crossing  sites  by  engineer  units  with 
fixed  bridging 

Figure  B-ll  (Continued  on  Next  Page) 


DESIRED  IMPROVEMENTS  TO  VIC  ENGINEER  REPRESENTATION 


Continued 


Task 

Code 

Improvement 

Mobility  (continued) : 

Pioneer  trails 

M16 

Add  capability  for  engineer  units  to  prepare 
and  maintain  pioneer  trails  (scripted  and 
dynamic ) 

Airlanding  facilities 

M17 

Add  capability  for  engineer  units  to  prepare 
and  maintain  forward  airlanding  facilities 
(scripted  and  dynamic) 

Survivability. 

Direct  fire  positions 

SV1 

Add  dynamic  capability  for  engineer  units  to 
prepare  fighting  positions 

SV2 

Add  dynamic  capability  for  engineer  units  to 
perform  subsequent  repairs  and  improvements  to 
fighting  positions 

Indirect  fire 

SV3 

Add  capability  for  engineer  units  to  prepare 

positions 

and  maintain  protective  positions  for  indirect 
fire  and  other  systems  (scripted  and  dynamic) 

Sustainment  engineering: 

Main  supply  routes 

ST1 

Add  capability  for  engineer  units  to  maintain 
and  repair  roads  ana  MSRs  (scripted  and 
dynamic) 

CS  and  CSS  sites 

ST2 

Add  capability  for  engineer  units  to  prepare 
and  maintain  sites  (scripted  and  dynamic) 

Figure  B-ll 


of  performing  one  of  four  specific  tasks.  Also,  non-engineer  maneuver  units 
should  accomplish  engineer- related  tasks  that  are  commensurate  with  their 
abilities  to  perform  them. 

(c)  The  tactical  effects  that  result  if  an  engineer  task 
is  (or  is  not)  performed  must  be  modeled.  The  tactical  effects  on  engineer 
units  performing  tasks  must  also  be  modeled. 

(d)  Unit  composition  and  equipment,  as  it  affects  task 
performance  capability,  should  he  identified.  Vulnerability  of  unit  assets 
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should  be  identified  and  attrition  must  be  assessed.  The  attrition  must,  in 
turn,  affect  task  performance  capability. 

(e)  It  is  important  that  the  model  limit  the  commitment  of 
engineer  units  to  realistic  performance  levels  --  to  include  degrading 
performance  due  to  night,  weather,  smoke,  and  NBC  effects.  Engineer  units 
must  be  constrained  to  the  capability  of  the  force  structure  in  the  scenario 
modeled . 

(f)  All  maneuver  unit  movements  should  encounter  the 
effects  of  terrain,  minefields,  and  other  linear  obstacles.  Maneuver  units 
should  be  capable  of  using  roads.  Roads  and  MSRs  should  be  subject  to 
degradation  through  use  or  attack. 

(2)  Countermobility. 

(a)  VIC  should  permit  rapid  reseeding  of  minefield  lanes 
during  retrograde  operations. 

(b)  VIC  should  allow  dynamic  site  selection  and  emplace¬ 
ment  of  minefields  and  linear  obstacles.  VIC  should  also  permit  rapid  closing 
of  lanes  in  minefields  and  other  linear  obstacles  during  retrograde. 

(c)  VIC  does  not  allow  manuever  units  to  take  advantage  of 
roads,  degradation  of  the  road  network,  and  modeling  of  point  obstacles.  When 
surrounding  terrain  does  not  permit  an  easy  bypass,  point  obstacles  can  have  a 
significant  role  in  battle  results.  The  capability  to  model  point  obstacles 
should  be  added  to  VIC  if  maneuver  units  are  allowed  to  take  advantage  of 
roads  or  pioneer  trails.  Further,  VIC  should  allow  a  synergistic  effect  to  be 
associated  with  point  obstacles  and  direct/indirect  fires. 

(d)  It  should  be  possible  to  dynamically  request  all 
countermobility  engineer  tasks  depending  on  battle  conditions.  Whether  the 
request  is  made  for  engineer  support  to  perform  the  task,  or  whether  it  is 
performed  with  resources  available  to  the  maneuver  unit,  depends  on  the 
existence  of  those  resources.  In  addition  to  the  dynamic  creation  of  these 
requirements,  VIC  should  also  dynamically  create  sites  for  these  tasks. 

(3)  Mobility. 

(a)  Except  for  tactical  bridging  operations,  VIC  does  not 
model  engineer  unit  performance  of  mobility  tasks.  VIC  should  model  requests 
for  engineer  unit  assistance  from  maneuver  and  other  units  encountering 
minefields  and  obstacles. 
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(b)  VIC  should  more  realistically  model  a  commander's 
selection  of  which  tactic  to  employ  (breach,  bull,  or  bypass)  when  encounter¬ 
ing  a  minefield. 

(c)  VIC  should  model  the  possibility  that  multiple 
breaches  of  a  linear  obstacle  may  be  prepared,  each  one  resulting  in  further 
reduction  of  obstacle  crossing  times. 

(d)  Available  intelligence  should  include  data  on  linear 
obstacle  breaches  in  accordance  with  rules  set  forth  by  intelligence  experts. 
VIC  should  permit  a  maneuver  unit  encountering  a  point  or  linear  obstacle  to 
consult  available  intelligence  to  determine  if  a  breach  has  already  been  made 
at  a  distance  that  would  permit  the  unit  to  dynamically  change  its  path  to 
take  advantage  of  the  breach. 

(e)  VIC  does  not  model  the  breach  of  a  point  obstacle; 
this  capability  should  be  added. 

(f)  VIC  should  model  the  improvement  of  a  wet  or  dry  gap 
crossing  site  with  an  engineer  task  to  install  fixed  bridging.  User  input 
should  control  the  rate  and  total  time  of  engineer  resource  expenditure. 
Bridging  materiel  should  be  modeled  in  VIC  as  distinct  entities  with  limited 
quantities.  Task  performance  should  result  in  reduced  obstacle  crossing 
rates . 

(g)  VIC  should  model  bridge  retrieval  tasks. 

(h)  VIC  should  model  the  preparation  and  maintenance  of 
pioneer  trails.  Task  performance  should  result  in  increased  grid  square 
trafficability. 

(i)  VIC  should  model  the  engineer  tasks  associated  with 
forward  airlanding  facilities  such  as  preparing  and  maintaining  helicopter 
landing  zones,  forward  arming  and  refueling  points,  low-altitude  parachute 
extraction  sites,  and  landing  strips. 

(4)  Survivability. 

(a)  VIC  does  not  model  degradation  of  direct  fire  posi¬ 
tions.  If  this  capability  is  added,  VIC  should  be  altered  to  permit  subse¬ 
quent  repair  and  improvement  tasks  associated  with  these  positions.  These 
tasks  should  be  generated  if  the  unit  expects  to  continue  to  occupy  the 
position  for  a  time  exceeding  a  user-defined  minimum  (improvement)  or  if  there 
has  been  mere  than  a  user-defined  minimum  degradation  (repair). 
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(b)  VIC  does  not  model  tasks  to  prepare  positions  for 
indirect  fire  and  other  systems. 

(5)  Sustainment  engineering. 

(a)  VIC  does  not  model  MSR  degradation  and  interdiction. 
This  should  be  added.  After  this  is  done,  VIC  should  be  further  improved  by 
adding  the  effects  of  engineer  tasks  to  repair  and  maintain  the  MSRs . 

(b)  VIC  does  not  model  a  corps'  rear-area  activities 
except  for  supply  operations  and  return- to-duty  for  soldiers  and  equipment. 

If  the  modeling  of  this  area  of  the  corps  is  strengthened  in  VIC,  then  the 
effects  of  engineer  tasks  to  prepare  and  maintain  various  CS  and  CSS  sites 
should  be  added. 

19 .  Conclus ions . 

a.  The  VIC  model  currently  represents  some  engineer  tasks  and  the 
effects  of  those  tasks  well.  However,  many  tasks  and  effects  are  represented 
poorly  or  not  at  all.  Therefore,  the  representation  of  engineers,  the 
execution  of  engineer  tasks,  and  the  results  from  the  execution  (or  non¬ 
execution)  of  those  tasks  need  improvement  in  VIC. 

b.  To  maintain  a  reasonable  and  balanced  representation  in  VIC, 
engineer  units  should  continue  to  be  modeled  with  explicit  maneuver  and  task- 
execution  capability.  However,  the  representation  of  engineer  unit  capability 
under  a  more  flexible  arrangement  could  improve  the  realism  of  the  current 
tasks  played  in  the  model  and  permit  adding  additional  engineer  tasks  that  are 
commonly  performed  in  a  corps'  area  of  operations. 

c.  The  analytic  community  is  currently  using  VIC  in  capability- 
constrained  studies,  not  requirements -unconstrained  studies.  The  use  of  VIC 
in  this  manner  is  not  expected  to  change  in  the  near  future.  Unless  VIC  is 
exported  to  users  outside  of  TRAC,  the  engineers  should  continue  to  be  modeled 
under  a  constrained  environment.  The  engineer  capability  to  perform  tasks  in 
VIC  should  be  limited  to  that  expected  of  the  engineer  force  as  defined  in  the 
VIC  scenario. 


V.  ANALYSIS  OF  ENHANCEMENTS  AND  RECOMMENDATIONS 


20.  General .  This  section  describes  results  of  the  analysis  of  the  37 
desired  improvements  listed  in  Figure  B-ll.  The  analysis  was  performed  in 
order  to  develop  a  logical,  prioritized  program  and  schedule  to  improve  the 
engineer  representation  in  the  VIC  model. 

21 .  Assessment  Results . 

a.  Evaluation  criteria.  Due  to  the  complexity  and  somewhat 
subjective  nature  of  this  analysis,  ESC  used  several  criteria  for  this 
evaluation.  The  criteria  were: 

The  likely  impact  of  the  improvement  on  model 
results 

Impact  of  improvements  on  VIC  run  time  and 
software  maintenance 

The  likely  impact  of  the  improvement  for 
engineer-specific  analysis 

Time  required  to  program  the  improvement 

Difficulty  in  providing  required  data  and 
tactical  decision  rules  (doctrine) 

The  logical  (predecessor/successor)  relation¬ 
ship  of  the  improvement  with  other  improvements 

Possible  reduction  in  programming  time  by 
grouping  the  improvement  with  others 

Coordination  required  (data  gathering  or 
specification  development)  outside  of  the 
engineer  community 

Degree  of  expected  acceptability  by  VIC  users 
or  the  VIC  proponent  (TRAC-WSMR) 

Together,  these  criteria  were  used  to  assess  which  improvements  should  be 
adopted  for  inclusion  in  VIC  and  the  order  in  which  they  should  be  addressed. 
ESC  did  not  assign  weighting  factors  to  the  criteria.  The  following  para¬ 
graphs  summarize  the  results  of  this  assessment  in  relationship  to  these 
criteria . 

b.  Impact  on  model  results.  The  tasks  from  Figure  B-ll  with  the 
greatest  potential  impact  on  model  results  are  tasks  G1  (revising  engineer 


unit  representation) ,  G7  (allowing  maneuver  units  to  use  the  road  network) ,  G8 
(degrading  and  damaging  roads),  CM3  (selecting  and  emplacing  linear  obstacles 
dynamically) ,  Ml  (dynamic  minefield  breaching  by  engineer  units) ,  M5  (dynamic 
linear  obstacle  breaching  by  engineer  units) ,  and  M13  (ensuring  that  gaps  that 
require  bridges  are  breached  only  by  using  bridges) .  Task  G6  (revising  the 
coordinated  group  move)  and  CM1  (adding  capability  for  air-delivered  scat- 
terable  mines)  are  also  rated  as  having  a  significant  potential  impact  on 
model  results.  These  tasks  were  scheduled  for  early  implementation,  unless 
other  evaluation  criteria  (for  example,  logical  sequencing  or  task  grouping) 
suggested  delayed  implementation. 

c.  Engineer-specific  analysis.  Even  though  it  has  no  impact  on 
model  results,  one  task  (task  G4,  adding  postprocessor  reports  for  engineer 
tasks)  is  included  as  an  improvement  to  VIC  because  it  is  important  for 
engineer-specific  analysis.  As  the  Army's  mid-resolution,  corps-level  model, 
ESC  believes  that  an  Engineer  Functional  Area  Model  (EFAM)  is  needed  to 
provide  a  more  detailed  analysis  related  to  engineer- specif ic  functions.  This 
analysis  model  would  be  used  by  an  agency  outside  of  TRAC  (that  is,  the  US 
Army  Engineer  School).  Therefore,  ESC  anticipates  that  the  results  of  VIC 
runs  will  be  used  for  analysis  by  an  EFAM.  These  results  would  be  captured 
within  VIC  postprocessor  reports  and  would  provide  valuable  data  relating  to 
the  engineer  tasks  performed  in  VIC  model  runs. 

d.  Impact  on  model  run  time.  Since  the  engineer  module  consumes 
only  a  small  part  of  VIC's  total  run  time,  ESC  believes  that  the  improvements 
added  to  the  engineer  module  will  have  a  only  minor  impact  to  the  overall  run 
time.  It  is  possible  that  improvements  to  the  efficiency  (execution  speed)  of 
existing  and  new  computer  code  could  actually  provide  a  net  decrease  to  the 
model's  run  time,  even  with  the  new  improvements  incorporated.  The  new 
computer  program  code  could  be  written  with  liberal  use  of  in-line  comments, 
meaningful  variable  names,  and  without  abstract  algorithms.  Such  code  should 
not  cause  significant  new  problems  for  the  model  proponent,  software  main¬ 
tenance  personnel,  and  model  users. 

e.  Level  of  effort.  With  the  exception  of  task  G7  (allowing 
maneuver  units  to  take  advantage  of  the  road  network) ,  ESC  believes  that  no 
individual  task  should  require  more  than  six  months  of  programming  effort. 

Most  should  require  much  less.  Several  could  be  completed  in  about  a  week. 
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The  greater  problem  is  the  availability  of  valid  data  and  tactical  decision 
rules  to  implement  the  new  computer  code.  This  evaluation  did  not  examine  the 
data  sets  being  used  by  VIC.  Resource  estimates  for  obtaining  data  sets  for 
the  proposed  improvements  are  estimated. 

f.  Sequencing.  Logical  sequencing  of  tasks  had  a  major  influence 
on  the  order  of  selection  of  tasks  for  implementation.  There  were  two  primary 
examples  of  this  effect. 

(1)  Because  the  representation  of  point  obstacles  would  have 
only  marginal  value  unless  maneuver  units  were  allowed  to  use  the  roads,  ESC 
postponed  this  improvement  until  the  use  of  roads  was  fully  implemented  in 
VIC.  Several  other  tasks  were  also  dependent  on  this  capability  being 
established  first. 

(2)  Rapidly  and  efficiently  adding  realistic  representation  of 
new  engineer  tasks  in  VIC  is  dependent  on  a  revised  representation  of  engineer 
units.  The  current  representation  in  VIC  is  believed  to  be  too  inflexible  to 
permit  easy  addition  of  new  engineer  unit  capabilities  and  model  the  effects 
of  personnel  and  equipment  attrition  on  task  performance  capability.  Thus, 

ESC  placed  the  task  to  improve  engineer  unit  representation  first. 

g.  Task  groupings.  Grouping  certain  sets  of  tasks  for  implementa¬ 
tion  as  a  "block"  could  reduce  the  total  amount  of  time  required  as  compared 
to  programming  each  task  individually.  Such  cases  were  considered  carefully 
to  determine  if  the  time  saved  was  worthy  of  raising  its  priority  for 
implementation. 

h.  Coordination.  Four  tasks  in  particular  will  require  coordina¬ 
tion  outside  of  the  engineer  community.  The  objectives  of  the  coordination 
are  both  to  achieve  a  consensus  for  the  specification  of  new  program  code  and 
to  assemble  a  reasonable  data  set  to  drive  the  new  code.  The  four  tasks  are 
G6  (revise  the  coordinated  group  move),  CM1  (add  aircraft  and  helicopter- 
delivered  minefields) ,  M17  (add  forward  airlanding  facility  engineer  tasks) , 
and  G7  (allowing  use  of  the  road  network  by  maneuver  units) .  Since  most  of 
the  code  to  be  revised  or  added  is  in  VIC  modules  which  are  primarily  outside 
of  the  influence  of  engineer  interactions  in  VIC,  it  is  preferable  that  the 
model  proponent  (TRAC-WSMR)  take  the  lead  in  initiating  these  improvements. 
This  arrangement  would  also  have  the  advantage  of  encouraging  and  enhancing 
the  acceptance  of  these  changes  by  other  model  users. 


22.  Recommendations .  This  analysis  resulted  in  the  regrouping  of  the 
37  improvement  tasks  identified  in  Figure  B-ll.  Figure  B-ll  grouped  improve¬ 
ments  according  to  engineer  functions.  The  new  grouping  places  these  tasks  in 
four  categories  for  a  phased  implementation. 

a.  Phase  One.  Figure  B-12  displays  the  improvement  tasks  that 
should  be  accomplished  first.  Although  fourteen  improvements  are  listed  in 
this  phase  and  should  begin  in  Phase  One,  only  four  of  the  improvements  in  the 
"general"  category  (Gl,  engineer  unit  representation;  G2 ,  ensuring  that  engi¬ 
neer  capability  of  non-engineer  units  is  commensurate  with  ability;  G3, 
degradations  to  engineer  task  performance;  and  G5 ,  adding  engineer  materiel 
resource  constraints)  are  expected  to  be  completed  by  the  end  of  this  phase. 
Six  improvement  tasks  will  not  be  complete  until  Phase  Two.  Programming  of 
these  six  tasks  can  begin  without  the  provision  of  data,  but  they  cannot  be 
completed  until  the  required  input  data  is  provided.  The  four  remaining  tasks 
(G6,  revise  coordinated  group  move;  G7,  allowing  maneuver  units  to  use  roads; 
CM1 ,  air-delivered  mines;  and  M17 ,  forward  airlanding  facilities  tasks)  may 
extend  into  a  later  phase.  Coordination  of  these  four  improvements  should  be 
begin  in  Phase  One,  but  the  length  of  time  for  this  coordination  with  the 
model  proponent  and  users  cannot  be  determined. 

(1)  Although  they  could  have  a  significant  impact  in  VIC,  task 
G8  (degrading  and  damaging  roads)  and  task  M13  (ensuring  that  gaps  that 
require  bridges  are  breached  only  by  using  bridges)  are  not  included  in  Phase 
One.  Instead,  they  are  placed  in  Phase  Two  to  allow  for  logical  sequencing 
and  grouping  of  these  improvements  with  others. 

(2)  The  major  improvement  tasks  in  Phase  One  are  the  revision 
of  VIC's  representation  of  engineer  units  --  their  resource  allocation, 
attrition,  degradations  to  performance,  and  supplies.  This  work  must  come 
first  to  provide  the  logical  framework  for  incorporating  additional  engineer 
task  improvements.  The  remaining  Phase  One  tasks  consist  of  establishing  the 
basis  for  incorporating  engineer  improvements  in  the  Engineer  Module  and 
Terrain  and  Barriers  Module. 

(3)  The  proposed  engineer  unit  representation  will  provide  a 
more  flexible  and  realistic  representation  of  engineer  capabilities  in  VIC. 


VIC  ENGINEER  REPRESENTATION 


PHASE  ONE  IMPROVEMENTS 


Task 

Code 

Inrorovement 

General : 

Gl 

Revise  engineer  unit  representation  and  method 
of  resource  allocation  Ensure  that  engineer 

attrition  is  modeled 

G2 

Ensure  that  engineer  task  performance  of  non¬ 
engineer  units  is  commensurate  with  ability 

G3 

Account  for  effects  of  night,  weather,  smoke, 
and  NBC  on  engineer  task  performance 

G5 

Fully  integrate  combat  engineers  and  their 
equipment  and  materiel  with  the  Logistics 
Module  and  Return- to  -  Duty  Module 

G6* 

Revise  VIC's  coordinated  group  move  logic  so 
that  maneuver  units  encounter  terrain  effects 

G7* 

Add  capability  for  maneuver  units  to  use  roads 

Countermobility : 

Minefields 

CMl* 

Add  capability  for  helicopter/aircraft- 
delivered  scatterable  mines 

Linear  obstacles 

CM3** 

Add  capability  for  dynamic  site  selections  and 
emplacements 

Mobility: 

Minefield  breaches 

Ml** 

Add  dynamic  capability  for  engineer  units  to 
breach  minefields 

M2** 

M4** 

Add  capability  to  request  breach,  including 
requests  from  units  bypassing  minefields 

Add  capability  for  subsequent  improvement  of 
minefield  breaches  by  engineer  units 

Linear  obstacle 

M5** 

Add  dynamic  request  and  capability  for 

breaches 

engineer  units  to  breach  linear  obstacles 

Airlanding  facilities 

M17* 

Add  capability  for  engineer  units  to  prepare 
and  maintain  forward  airlanding  facilities 
(dynamic  and  scripted) 

Survivability: 

Direct  fire  positions 

SV1** 

Add  dynamic  capability  for  engineer  units  to 
prepare  fighting  positions 

Indirect  fire 

SV3** 

Add  capability  for  engineer  units  to  prepare 

positions 

protective  positions  for  indirect  fire  and 
other  systems  (scripted  and  dynamic) 

^Coordination  for 

adding 

this  improvement  to  VIC  begins  in  this  phase. 

If  approved,  the  task  will  be  c 

ompleted  in  a  later  phase. 

Task  completion 

will  extend  into  Phase  Two. 

Figure  B-12 
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Rather  than  using  teams  with  fixed  capability,  engineer  units  will  be  task- 

organized  as  needed  to  perforin  specific  missions.  All  engineer  assets  will 

belong  to  a  "superior"  engineer  unit  and  will  be  assigned  to  work  units  as 

needed  to  accomplish  specific  missions.  This  form  of  representation  will 

improve  the  current  engineer  representation  in  the  following  ways: 

Allows  for  variable  resolution  of 
resource  representation 

Provides  a  mechanism  for  improved, 
dynamic  engineer  force  structure 
representation 

Models  multi-mission  capability  of 
engineer  resources 

(4)  ESC  estimates  that  computer  programming  efforts  require 
about  six  calendar  months  and  one  professional  staff  year  of  effort  to  support 
Phase  One.  Only  minimal  guidance  on  concepts  and  doctrine  will  be  needed  in 
this  phase.  About  one  professional  staff  month  is  needed  to  gather  the  data 
for  this  first  phase.  Both  parts  of  the  overall  effort  can  begin  simul¬ 
taneously  . 

b.  Phase  Two.  Figure  B-13  lists  the  tasks  for  Phase  Two.  Every 
task  in  this  figure  should  be  completed  at  the  end  of  Phase  Two.  Any  task 
involving  dynamic  capabilities  must  have  tactical  decision  rules  identified  to 
determine  which  conditions  encountered  during  model  play  will  call  for  the  new 
capability  to  be  exercised.  The  concepts  and  doctrine  for  these  decision 
rules  must  be  provided  before  computer  programming  can  begin. 

(1)  The  Phase  Two  work  will  enhance  VIC  engineer  representation 
in  two  areas.  First,  the  foundation  that  began  in  Phase  One  for  incorporating 
a  host  of  engineer  tasks  will  provide  a  more  complete  set  of  engineer  task 
effects  for  gaming  in  VIC.  Second,  task  G4  (adding  engineer  postprocessor 
reports)  will  be  implemented  to  extract  engineer- related  task  data  from  VIC. 

(2)  Phase  Two  work  involves  about  one  professional  staff  year 
of  programming  effort  over  a  six-month  time  period.  Data  gathering  and 
generation  of  tactical  decision  criteria  from  doctrine  could  be  difficult  and 
could  require  as  much  as  two  professional  staff  months.  The  tactical  decision 
data  must  be  provided  before  computer  programming  can  begin,  so  this  effort 
should  start  well  in  advance  of  the  start  date  of  the  programming  effort. 
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VIC  ENGINEER  REPRESENTATION 


PHASE  TWO  IMPROVEMENTS 


Task 

Code 

Improvement 

General : 

G4 

Add  postprocessor  reports  that  capture 
performance  (and  non-performance)  of  all 
engineer  tasks 

G8 

Add  capability  to  degrade  and  damage  roads 
and  MSRs 

Countermobility : 

Linear  obstacles 

CM3* 

Add  capability  for  dynamic  site  selections  and 
emplacements 

Mobility: 

Minefield  breaches 

Ml* 

Add  dynamic  capability  for  engineer  units  to 
breach  minefields 

M2* 

Add  capability  to  request  breach,  including 
requests  from  units  bypassing  minefields 

M4* 

Add  capability  for  subsequent  improvement  of 
minefield  breaches  by  engineer  units 

Linear  obstacle 

M5* 

Add  dynamic  request  and  capability  for 

breaches 

engineer  units  to  breach  linear  obstacles 

M8 

Add  capability  for  subsequent  improvements  of 
linear  obstacle  breaches  by  engineer  units. 

Assault  river 

M13 

Ensure  that  gaps  which  require  bridging  cannot 

crossings 

be  breached  without  bridging 

M14 

Explicitly  model  bridge  asset  availability 
linear  obstacle  breaches  by  engineer  units 

Survivability: 

Direct  fire  positions 

SV1* 

Add  dynamic  capability  for  engineer  units  to 
prepare  fighting  positions 

Indirect  fire 

SV3* 

Add  capability  for  engineer  units  to  prepare 

positions 

protective  positions  for  indirect  fire  and 
other  systems  (scripted  and  dynamic) 

Task  began  in  Phase  One 

and  will  be  completed  in  this  phase. 

Figure  B-13 
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c.  Phase  Three.  Figure  B-14  displays  the  tasks  that  are  scheduled 
for  completion  in  the  third  phase  of  VIC  improvement  effort.  In  general, 
these  tasks  are  associated  with  lower-priority  engineer  tasks  (in  terms  of 
impact  on  model  outcome)  and/or  require  additional  programming  time  than  the 
tasks  addressed  in  phases  one  and  two.  Phase  Three  effort  is  expected  to 
require  about  six  calendar  months  and  one  professional  staff  year  of  program¬ 
ming  effort.  Only  a  minimal  effort  will  be  necessary  to  provide  guidance  on 
concepts  and  doctrine  for  the  programming  work.  The  data  provision  require¬ 
ment  for  this  task  is  estimated  at  roughly  one-half  professional  staff  month. 


VIC  ENGINEER  REPRESENTATION  --  PHASE  THREE  IMPROVEMENTS 


Task 

Code 

Improvement 

Countermobility : 

w 

Complex  obstacles 

CMS 

Add  dynamic  capability  for  engineer  units  to 
emplace  complex  obstacles 

Mobility: 

« 

Complex  obstacle 
breaches 

M9 

Add  dynamic  capability  for  engineer  units  to 
breach  complex  obstacles 

River  crossing  sites 

M15 

Add  capability  for  subsequent  improvement  of 
river  crossing  sites  by  engineers  with  fixed 
bridging 

ft 

Sustainment  engineering: 

Main  supply  routes 

ST1 

Add  capability  for  engineer  units  to  maintain 
and  repair  roads  and  MSRs  (scripted  and 
dynamic) 

' 

CS  and  CSS  sites 

ST2 

Add  capability  for  engineer  units  to  prepare 
and  maintain  sites  (scripted  and  dynamic) 

Figure  B-14 


d.  Other  improvements.  Figure  B-15  lists  tasks  which  fall  into  two 
categories:  (1)  those  improvements  that  are  dependent  on  coordination  outside 

of  the  engineer  community;  and  (2)  those  improvements  that  represent  desir¬ 
able,  but  not  required,  additions  to  VIC.  Coordination  of  the  four  tasks 
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VIC  ENGINEER  REPRESENTATION 


OTHER  IMPROVEMENTS 


Task 

Code 

Irrrorovement 

General : 

Countermobility: 

G6* 

G7* 

Revise  VIC's  coordinated  group  move  logic  so 
that  maneuver  units  encounter  terrain  effects 
Add  capability  for  maneuver  units  to  use  roads 

Minefields 

CM1* 

Add  capability  for  helicopter/aircraf t - 
delivered  scatterable  mines 

Point  obstacles 

Mobility: 

CM6** 

CM7** 

Add  capability  for  scripted  and  dynamic 
point  obstacle  emplacements 

Allow  synergistic  effects  of  point  obstacles 

Minefield  breaches 

M3 

Add  more  parameters  for  selecting  the 
appropriate  minefield  breaching  tactic 
(bypass,  bull,  breach) 

Linear  obstacle 
breaches 

M6 

M7 

Add  capability  to  search  for  nearby  paths 
across  obstacles  before  breaching 

Add  capability  to  create  multiple  breaches  on 
a  single  linear  obstacle  segment 

Point  obstacle 

M10** 

Mil** 

Add  capability  for  engineer  units  to  breach 
point  obstacles 

Add  capability  for  non-engineer  units  to 
breach  point  obstacles  or  request  engineer 
unit  support 

Assault  river 
crossings 

M12 

Add  capability  to  cross  gaps  by  means  other 
than  bridging  (fording,  bypass,  breaching) 

Pioneer  trails 

M16** 

Add  capability  for  engineer  units  to  prepare 
and  maintain  pioneer  trails  (scripted  and 
dynamic) 

Airlanding  facilities 

M17* 

Add  capability  for  engineer  units  to  prepare 
and  maintain  forward  airlanding  facilities 
(scripted  and  dynamic) 

Coordination  for  adding  this  task  began  in  Phase  One . 

Task  is  contingent  on  the  completion  of  task  G7 . 

Figure  B-15 
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which  fall  in  the  first  category  began  in  Phase  One  because  of  the  anticipated 
lead  time  and  interaction  that  must  take  place  with  the  model  proponent  and 
users.  They  must  understand  that  the  primary  benefit  of  these  revisions  in 
the  model  is  to  provide  more  realism  in  VIC  results.  They  must  also  accept 
that  scenario  development  will  not  become  more  difficult  and  model  run  time 
will  not  be  adversely  affected.  Because  of  the  uncertainty  surrounding  these 
tasks,  manpower  and  time  estimates  necessary  to  accomplish  these  improvements, 
even  given  an  existing  specification,  cannot  be  made  at  this  time. 

(1)  Task  G6  (modify  coordinated  group  move  code  to  ensure  that 
all  manuever  units  are  subject  to  terrain  effects)  will  likely  have  a 
significant  impact  on  the  results  of  model  play.  This  improvement  is  neces¬ 
sary  to  ensure  that  terrain  effects  are  adequately  represented.  The  engineers 
should,  through  the  VMUG ,  take  the  lead  in  this  revision  to  VIC. 

(2)  Task  G7  (adding  capability  for  maneuver  units  to  use 
roads),  as  previously  discussed,  is  a  very  difficult  task  to  implement. 
Proponency  for  developing  the  task  specification  cannot  logically  be  assigned 
to  a  single  organization  due  to  magnitude  of  its  impact  on  many  functional 
areas.  The  engineers  should  also  take  the  lead  in  attaining  this  capability 
in  VIC.  If  task  G7  is  eventually  implemented  in  VIC,  then  work  could  begin  on 
tasks  that  relate  to  roads  and  point  obstacles  (CM6,  CM7 ,  M10 ,  Mil,  and  M16) . 

(3)  The  majority  of  the  new  computer  program  code  which  mur*-  be 
developed  in  response  to  task  CM1  (helicopter/aircraft-delivered  minefields) 
will  be  in  VIC  modules  that  are  not  currently  influenced  by  engineer-related 
modules.  Again,  outside  coordination  may  be  necessary.  Due  to  insufficient 
experience  in  the  engineer  community  of  the  characteristics  of  the  existing 
code  that  would  have  to  be  modified,  ESC  is  unable  to  specify  the  programming 
changes  necessary  to  implement  this  task.  Therefore,  manpower  and  time 
requirements  cannot  be  estimated. 

(4)  Task  M17  (forward  airlanding  facilities)  has  several 
factors  not  supporting  its  early  incorporation  in  the  VIC  improvement  program. 
The  impact  of  implementing  this  task  in  VIC  is  not  known  due  to  the  engineer 
community's  unfamiliarity  with  the  Global  Air  Module  and  the  other  related 
modules.  It  is  anticipated  that  data  provision  would  be  very  difficult  and 
that  several  other  modules  would  be  impacted.  Further,  it  would  be  difficult 
to  validate  the  accuracy  of  data  supporting  the  new  code. 


(5)  The  remaining  tasks  in  Figure  B-15  are  additions  to  VIC 
that  ESC  considers  to  be  less  important  to  the  overall  representation  of 
engineer  effects. 

(a)  Task  M3  (adding  additional  selection  criteria  for 
minefield  breaches) ,  if  implemented,  would  provide  an  improvement  to  a 
capability  that  VIC  models  fairly  well  already.  The  effort  to  develop 
tactical  decision  rules  to  govern  choice  of  minefield  breaching  tactic  would 
be  difficult,  and  in  most  cases  would  yield  results  in  agreement  with  what  VIC 
currently  provides.  Therefore,  this  task  should  be  delayed  to  near  the  end  of 
the  effort  to  upgrade  VIC's  engineer  representation  due  to  the  perceived 
difficulty  of  implementing  the  task  (from  a  data  standpoint)  and  the  marginal 
incremental  improvement  that  would  ensue. 

(b)  Task  M7  (creating  multiple  breaches  on  a  single  linear 
obstacle  line  segment)  could  be  handled  by  alternative  methods,  such  as  simply 
using  smaller  line  segments. 

(c)  Task  M12  (crossing  gaps  by  means  other  than  bridging) 
would  be  difficult  to  implement  (also  from  the  standpoint  of  data 
availability)  and  would  provide  a  relatively  minor  impact  on  model  outcomes. 
Terrain  data,  in  general,  is  not  available  in  sufficient  resolution  to  drive 
the  tactical  decision  rules  that  would  be  required  to  govern  the  selection  of 
a  specific  breaching  technique. 

e.  Omitted  tasks.  Three  tasks  from  Figure  B-ll  were  omitted  as  a 
result  of  this  analysis  of  improvements.  The  relative  impact  of  task  SV2 
(dynamically  repair  and  improve  direct  fire  positions)  on  model  results, 
compared  with  the  difficulty  of  implementing  it  in  the  model,  is  not  sig¬ 
nificant  enough  to  warrant  the  expenditure  of  effort.  Not  only  would  the 
repair  task  have  to  be  modeled,  but  the  code  to  generate  the  weathering  and 
damage  (and  their  effects  on  vulnerability)  would  also  have  to  be  developed. 
Lastly,  tactical  decision  rules  to  specify  the  conditions  under  which  repair 
would  be  requested  would  also  have  to  be  generated.  Also,  the  engineer 
improvement  tasks  for  adding  capability  to  close  lanes  in  minefields  (CM2)  and 
other  linear  obstacles  (CM4)  were  judged  to  have  only  marginal  value.  VIC's 
current  terrain  resolution  is  not  sufficiently  detailed  to  model  this  task. 


f.  Other  recommendations. 

(1)  With  the  improvements  described  above,  ESC  believes  that 
VIC  will  yield  results  that  would  be  generally  consistent  with  a  more-detailed 
representation  of  engineer  capability  in  a  model  such  as  that  proposed  in  an 
EFAM.  (See  Annex  D,  "Engineer  Functional  Area  Model.") 

(2)  The  first  three  phases  of  improvements  as  described  in 
Figures  B-12,  B-13,  and  B-14  should  be  resourced  and  sequentially  implemented. 
It  is  important  to  note  that  before  programming  can  begin,  the  tactical 
decision  rules  for  executing  engineer  tasks  must  be  specified.  Data  sets  to 
support  these  improvements  could  be  developed,  for  the  most  part,  in  parallel 
with  model  programming. 

(3)  TRAC-WSMR  is  the  model  proponent  and  would  be  the  most 
likely  organization  to  make  these  recommended  programming  changes.  However, 
TRAC-WSMR  has  recently  lost  its  two  most  senior  VIC  programmers,  and  it 
continues  to  aggressively  accomplish  a  heavy  study  workload  using  VIC. 
Therefore,  ESC  recommends  that  CERL  be  designated  as  the  programming  activity, 
tasked,  and  funded  to  make  these  improvements  because  of  CERL's  prior 
experience  in  working  with  VIC. 

(4)  CERL  would  have  the  responsibility  to  work  with  TRAC-WSMR 

to  validate  the  software  developed  and  demonstrate  the  effects  of  the  software 

on  the  model  as  a  whole.  CERL  would  also  have  the  responsibility  for  docu¬ 

menting  the  software  for  both  users  and  programmers. 

(5)  The  US  Army  Engineer  School  (USAES)  should  have  the 
responsibility  for  providing  the  concepts  and  doctrine  to  support  the  program¬ 
ming  of  the  tactical  decision  rules.  The  USAES  should  also  haw  ..he  lead 
responsibility  (in  conjunction  with  the  US  Army  Materiel  Systems  Analysis 
Activity)  for  providing  the  data  sets  to  support  the  model.* 

(6)  As  the  facilitator  of  engineer  model  initiatives,  ESC  will 

continue  to  monitor  and  coordinate  with  the  engineer  and  modeling  community  to 

ensure  that  the  VIC  engineer  model  improvement  program  remains  on  track. 

ESC's  role  includes  monitoring  and  coordinating  the  development  of  data  sets 
and  tactical  decision  rules  for  some  of  the  improvements  that  primarily  affect 

^Due  to  the  impending  move  of  the  USAES  to  Fort  Leonard  Wood,  the  USAES 
may  be  unable  to  support  this  effort  on  a  timely  basis. 


the  engineers  and  ensuring  that  the  model  proponent  and  users  agree  in 
principle  to  the  improvements  in  engineer  representation  in  VIC. 

g.  Interim  Measures.  Until  the  improvements  described  above  are 
implemented  in  VIC,  the  scenario  developers  and  other  model  users  should 
immediately  strive  to  implement  the  thrust  of  these  recommendations  through 
input  data.  For  example: 


Represent  linear  obstacles  as  short  segments  so 
that  breaching  a  single  segment  will  not  create 
an  artificially  large  gap  in  the  obstacle. 

Use  pseudo- inf inite  breach  times  for  major 
river  crossings  for  maneuver  units  without 
bridge  assets.  This  will  prevent  units  from 
performing  a  breach  that  is  physically 
impossible . 

Use  coordinated  move  groups  as  sparingly  as 
possible  consistent  with  maintaining  reasonable 
model  run  times.  Units  in  a  coordinated  group 
move  status  do  not  encounter  terrain  features, 
including  minefields  and  other  obstacles.  This 
is  unrealistic  and  masks  the  value  of  engineer 
support . 
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I.  INTRODUCTION 


1.  Purpose .  This  annex  examines  engineer  play  in  the  Force  Evaluation 
Model  (FORCEM) ,  discusses  different  methods  to  improve  its  engineer  represen¬ 
tation,  and  finally  presents  a  strategy  for  achieving  the  desired  improvements. 

2.  Scope .  This  review  of  FORCEM  is  deliberately  focused  on  engineer 
play  ana  parallels  the  assessment  cf  engineer  representation  in  other  major 
Army  models  being  made  by  the  US  Army  Engineer  Studies  Center  (ESC) .  Other 
functional  areas  and  model  elements  were  examined  only  to  the  extent  that  they 
influence,  or  should  influence  the  use  of  engineer  forces.  Particular  aspects 
of  the  model  that  hamper  or  frustrate  the  representation  of  engineer  play  are 
identified  and  in  some  cases  included  as  part  of  the  proposed  changes. 

3.  Background .  FORCEM  is  an  automated,  two-sided,  time  -  stepped ,  deter¬ 
ministic,  and  symmetric  theater- level  war  game.  It  plays  both  ground  and  air 
combat.  Unlike  most  other  theater  models,  it  has  a  multi-tiered  decision¬ 
making  framework,  represents  combat  service  support  (CSS)  forces  at  echelons 
above  corps  (EAC) ,  and  has  the  ability  to  show  the  impact  on  combat  of  support 
capabilities  and  shortfalls.  The  following  paragraphs  give  some  perspective  to 
what  FORCEM  is . 

a.  Theater-level  models.  The  complexities  of  modern  warfare  (the 
costs,  the  types  of  forces,  the  theater,  the  weapons,  etc.)  make  it  impossible 
to  plan  for  and  allocate  the  resources  necessary  to  ensure  the  defense  of  the 
United  States  (US)  and  the  protection  of  its  national  interests  without 
extensive  data  and  computational  support.  High-resolution  models,  simulating 
weapon  or  small  unit  engagements  can  use  detailed  (often  mathematical)  repre¬ 
sentations  of  performance  characteristics,  line-of-sight,  communications,  etc. 
Models  that  examine  warfare  on  a  large  scale,  i.e.,  theater  or  global  simula¬ 
tions  such  as  TACWAR-'-  or  CEM^ ,  must  generalize  components  and  effects.  These 
lower-resolution  models  are  physically  unable  to  include  every  conceivable 
contributing  component  in  a  model,  and  are  unable  to  predict  the  vagaries  of 
large  force  on  force  actions.  More  importantly,  they  cannot  duplicate  the 
human  element  in  strategic  decisionmaking.  These  shortcomings  are  frequently 

^Kerlin,  Edward,  IDA  TACNUC  Model:  Theater-Level  Assessment  of  Conven¬ 
tional  and  Nuclear  Combat  (Institute  for  Defense  Analysis,  October  1975). 

^Concepts  Evaluation  Model  (CEM)  (US  Army  Concepts  Analysis  Agency  [CAA]). 
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criticized  by  both  the  government  (a  General  Accounting  Office  [GAO]  report-* 
confirmed  the  need,  but  challenged  model  and  results  verification  procedures) 
and  private  reviewers  (see  Allen^  for  a  current,  albeit  alarmist  view  of  how 
war  games  have  evolved  and  have  been  used  in  making  decisions) .  Despite  these 
criticisms,  theater  models  are  accepted  tools  for  planners  and  have  become 
indispensable  adjuncts  to  the  decisionmaking  process. 

b.  History  of  FORCEM.  In  July  of  1981  an  Army  Regulation  (AR) 
ordained  a  hierarchy  of  war  games  at  the  theater,  corps/division,  combined 
arms,  and  support  task  force  levels. ^  These  models  would  be  developed  and 
implemented  to  facilitate  the  evaluation  of  combat  capabilities  and  determine 
resource  requirements.  The  impetus  for  the  program  came  from  the  "Hardison 
Report,"  an  examination  sponsored  by  the  Deputy  Undersecretary  of  the  Army 
(Operations  Research)  of  Army  study  organizations  and  products.**  The  report 
found  a  proliferation  of  models,  systems,  and  games  (MSGs)  that  could  neither 
be  linked  together  nor  used  with  common  data  bases.  The  regulation  further 
tasked  CAA  with  developing  the  theater  model.  CAA  initially  planned  to  modify 
its  CEM  model  to  achieve  the  goals  of  FORCEM.  In  the  spring  of  1982,  however, 
CAA  rejected  this  concept  in  favor  of  an  entirely  new  design  effort.  Develop¬ 
ment  proceeded  through  the  period  1982  to  1985  when  the  first  working  version 
was  completed.  Important  to  the  purpose  of  this  annex  was  the  work  performed 
by  the  US  Army  Construction  Engineering  Research  Laboratory  (CERL) .  It  col¬ 
laborated  with  CAA  in  designing  an  engineer  submodel  for  FORCEM. 

c.  Model  usage.  FORCEM  has  been  used  on  three  major  CAA  studies: 

US  Army  Operational  Readiness  Analysis- 1985  (OMNI^US-85) ,  OMNIBUS-86,  and  the 
Combat -Support  Ratio  Study.  FORCEM  was  used  in  the  first  study  for  demonstra¬ 
tion  purposes,  while  the  latter  two  efforts  were  full-fledged  study 


^ Models ,  Data,  And  War:  A  Critique  of  the  Foundation  For  Defense  Analyses 
(Comptroller  General  of  the  United  States,  12  March  1980). 

^Allen,  Thomas  B.,  War  Games  (McGraw  Hill,  1987). 

-’Army  Model  Improvement  Program  (AMIP) ,  AR  5-11  (July  1981). 

^Review  of  Army  Analysis  (Department  of  the  Army  [DA]  Special  Study  Group, 
April  1979) . 


applications.  The  model  is  expected  to  become  CAA's,  and  therefore,  the  Army's 
primary  theater-level  model. 

d.  Configuration  management.  CAA  is  currently  the  exclusive  owner 
and  operator  of  the  model.  While  other  Army  war  game  designing  organizations 
have  instituted  standardization  groups  to  control  the  proliferation  of  unregu¬ 
lated  or  undocumented  model  versions,  no  other  Army  agency  or  element  has  a 
mission  which  overlaps  the  theater-level  analyses  that  CAA  conducts.  The 
overhead  in  running  a  FORCEM- sized  model  will  probably  discourage  other 
agencies  from  acquiring  it,  if  the  experience  with  the  CEM  is  any  indication. 
Thus,  changes  to  the  model,  whether  internally  or  externally  generated,  would 
likely  be  implemented  and  controlled  by  CAA. 

4.  Method .  The  approach  ESC  used  for  this  assessment  proceeded  as 
follows: 

a.  First,  the  FORCEM  model  was  studied  to  identify  its  major  func¬ 
tional  areas  and  review  the  engineer  representation  (structure  and  procedures) . 
Those  model  elements  that  would  directly  or  indirectly  influence  engineer  play 
were  also  examined. 

b.  Second,  ESC  reviewed  the  engineer  missions  that  are  applicable  to 
the  FORCEM  environment,  especially  engineer  missions  at  EAC. 

c.  Third,  was  the  key  phase  in  which  real  world  engineer  missions 
were  compared  to  FORCEM' s  present  representation.  This  comparison  considered 
adequacy  of  representation,  effect  on  the  model,  and  difficulty  and  extent  of 
modifications,  if  necessary. 

d.  Finally,  a  list  of  recommended  actions  was  prepared  to  be  used  in 
developing  the  overall  plan  to  improve  engineer  modeling  in  the  Army. 


II.  DESCRIPTION  OF  THE  MODEL 


5.  Sources .  Although  FORCEM  has  been  used  as  the  analytical  basis  for 
several  major  CAA  studies,  the  model  continues  to  evolve.  As  with  most 
computer  systems,  changes  to  documentation  lag  behind  code  and  logic  revisions. 
Consequently,  there  is  no  published  document  that  reflects  the  current  state  of 
the  model  and  all  its  components.  Separate  documents  of  varying  currency  and 
accuracy  exist  for  Fire  Support,  Command  and  Control  (C^) ,  Movement,  CSS,  Data 
Input,  and  Model  Output.  ESC  had  to  supplement  existing  documentation  with  a 
review  of  FORCEM' s  code  and  discussions  with  CAA  personnel.  ESC  also  used 
various  documents  prepared  by  CERL  describing  existing  and  proposed  engineer 
module  structures  and  logic. ^ >8 

6 .  Operational  Environment . 

a.  Hardware  and  Systems  Software.  As  with  any  computer  model,  the 
structure  of  FORCEM  is  very  much  a  product  of  the  computer  hardware  and 
software  environment  in  which  it  is  implemented.  It  is  implemented  on  a  UNISYS 
1100/84  computer  having  4  mega-words  (36  bits)  of  main  memory,  and  uses  the 
EXEC  operating  system.  The  model  is  written  in  SIMSCRIPT  II.  5,  which,  not 
coincidentally,  is  the  language  in  which  the  other  Army  models  in  the  hierarchy 
are  written.^  Several  early  portions  of  the  model  were  written  in  FORTRAN,  but 
they  were  later  converted  to  SIMSCRIPT  for  consistency. 

b.  Software.  Here  we  will  distinguish  systems  software  (compilers 
and  operating  system)  from  the  user-created  software  that  would  be  used  in  a 
FORCEM  application.  Figure  C-l  shows  the  major  programs  that  would  be  used  in 
any  study  using  FORCEM.  Note  that  the  entries  within  the  boxes  are  programs: 
TRANSMO  is  a  strategic  mobility  model;  ATCAL  extrapolates  division  results  from 
combat  samples  (force  composition  and  combat  attrition  data);  and  COSAGE  is  a 
model  developed  at  CAA  initially  for  the  analysis  of  wartime  ammunition, 

''Evans,  John  W.  ,  Conceptual  Design  of  the  Engineer  Module  for  the  Theater- 
Level  Force  Evaluation  Model  (FORCEM) ,  Technical  Report  P-87/15  (USA-CERL, 
September  1987) . 

^"Engineer  Representation  in  the  Force  Evaluation  Model  (FORCEM),"  letter 
from  CERL  to  ESC,  24  December  1987. 

^Kiviat,  et.  al . ;  edited  by  E.  C.  Russell,  SIMSCRIPT  II. 5  Programming 
Language  (CACI,  Inc.,  1975). 
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FORCEM's  SOFTWARE  ENVIRONMENT 


personnel  and  materiel,  which  generates  the  combat  samples  needed  by  ATCAL.^® 
Other  entries  in  the  Figure  indicate  input  and  output  data. 

c .  Temporal  relationships . 

(1)  Linkage  is  an  important  aspect  of  FORCEM.  In  the  original 
concept  of  the  Army's  model  hierarchy,  FORCEM  was  to  use  the  results  of  the 
Corps-level  model,  Corps/division  evaluation  model  (CORDIVEM) ,  to  evaluate 
divisional  combat,  rather  than  containing  its  own  evaluative  routines.  It  was 
envisioned  as  parameter  lists  passing  situation  and  results  between  the  two 
models,  much  like  uplink  and  downlink  vectors  of  data  pass  between  an  earth 
station  and  a  satellite,  ergo  the  term  linkage.  Problems  and  the  subsequent 
demise  of  CORDIVEM,  however,  forced  CAA  to  use  its  own  division- level  model, 
COSAGE,  to  provide  the  necessary  data  from  which  weapon-on-target  results  can 
be  calculated  within  FORCEM.  (CAA  has  the  Vector- in-Commander  [VIC]  model, 
which  has  replaced  CORDIVEM  in  the  AMIP.H  Moreover,  the  process  to  link  VIC 
results  to  FORCEM  has  been  conceptualized,  and  is  expected  to  be  implemented  by 
the  Fall  of  1988.) 

(2)  The  last  components  in  the  environment  are  the  pre-  and 
post-processors  that  are  significant  elements  in  the  preparation  and  analysis 
of  FORCEM  applications.  Programs  extract  information  from  several  Army  data 
bases  to  create  the  force  description  input,  and  the  deployment  schedule  of 
arriving  troops.  The  Force  Analysis  Simulation  of  Theater  Administrative  and 
Logistics  (FASTALS)  model  is  particularly  important  for  the  engineer  force 
structure.  c  It  is  a  post-processor  that  performs  force  "round  out",  i.e.,  it 
develops  a  list  of  non-divisional  engineer  forces  necessary  to  support  the 
combat  force.  According  to  FORCEM 's  AR  5-11  charter,  the  model  was  to  be 
capable  of  generating  force  requirements .  Although  much  thought  has  been  spent 
on  how  this  might  be  accomplished,  it  is  unlikely  that  anything  but  FASTALS 
will  be  used  for  the  near  future. 

^-^Wartime  Requirements  for  Ammunition ,  Materiel ,  and  Personnel ,  Volume  V, 
Combat  Sample  Generator  User's  Manual  (COSAGE)  (October  1982). 

^Gamble,  Alan,  and  Richard  Porter,  Vector- in-Commander  (VIC)  Documenta¬ 
tion  (US  Army  TRADOC  Analysis  Command,  White  Sands  Missile  Range  [TRAC-WSMR] , 

June  1987). 
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LLForce  Analysis  Simulation  of  Theater  Administrative  and  Logistics 
Support  Model  (FASTALS) ,  prepared  for  the  US  Army  Logistics  Center  (Computer 
Sciences  Corporation,  April  1980). 


7.  Functional  Processes.  The  easiest  way  to  introduce  FORCEM's  func¬ 
tions  is  by  showing  its  logic  structure  (see  Figure  C-2) .  From  it,  one  can  see 
that  there  are  three  major  areas:  situation  development,  ,  and  the 
activities  that  actually  change  the  states  of  various  model  elements.  These 
areas  will  be  briefly  discussed  to  present  an  overview  of  the  model.  The 
processing  flow  of  the  model  parallels  the  chart  in  that  it  generally  cycles 
each  period  from  left  to  right  across  the  functions. 


FORCEM's  FUNCTIONAL  STRUCTURE 
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Figure  C-2 


a.  Situation  Development.  Each  time -step  begins  by  checking  the 
input  files  for  unit  and  supply  arrivals  or  externally  directed  events  (such  as 
port  or  air  base  attacks).  This  is  followed  by  the  gathering  and  processing  of 
intelligence  information  and  the  transmission  of  that  information  among  the 
headquarters'  units,  as  part  of  building  a  perception  base.  Information  about 
enemy  forces  is  collected  by  sensors  owned  by  units.  Communications  between 
units  are  handled  through  messages,  which  can  be  delayed  if  traffic  exceeds 
stated  inter-echelon  channel  capacities. 

b.  Command  and  Control  (C^)  .  The  C2  process  examines  the  situation 
at  the  echelons  above  division  (EAD) ,  i.e.  Corps,  Army,  and  theater 
headquarters,  prior  to  making  decisions  affecting  units  and  resources . “ 
Decisionmaking  is  automated  and  is  a  function  of  hard-wired  decision  rules  and 
various  other  control  parameters  defined  by  input  variables  that  set  thresh¬ 
olds,  ratios,  or  ranges  against  which  the  rules  are  evaluated. 

c.  Activities.  Whereas  information  is  assimilated  and  planning  is 
developed  in  the  other  portions  of  FORCEM,  most  operations  occur  at  the 
activity  level.  Units  are  moved  depending  on  various  objectives  for  forward 
area  troops,  the  destination  for  units  arriving  in  theater,  and  layouts  for 
units  subordinated  to  C2  units. I4  Combat  occurs  at  several  levels:  at  the 
maneuver-unit  level;  in  the  full  range  of  roles  for  air  war;  and  in  the  deep 
strike  capability  of  EAD  artillery  and  surface  to  surface  missiles.  The  latter 
two  comprise  the  fire  support  function . ^  And  last,  are  various  activities  in 
the  CSS  area. Conceptually,  the  engineer  submodule  appears  under  CSS 
although  it  would  be  relatively  independent  of  other  CSS  modules. 

8.  Units.  Within  FORCEM  the  "unit"  plays  a  crucial  and  pervasive  role. 
In  an  effort  aimed  at  uniformity  and  reduction  of  data  structures,  a  decision 
was  made  to  use  a  single  template  for  all  units.  It  is  important  to  understand 
the  direct  and  indirect  use  of  FORCEM  units.  Figure  C-3  shows  the 

1  O 

■“Metzger,  James  J.,  Command  and  Control  in  the  Force  Evaluation  Model 
(CAA,  14  January  1986) . 

14F0RCEM  Movement  (CAA,  13  March  1986). 

1-^Byrne,  P.  C.,  The  FORCEM  Fire  Support  Module  (CAA,  May  1986). 

l^Fi  ORCEM  Combat  Service  Support  (CAA,  20  February  1986). 
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Figure  C-3 

kinds  of  units  and  the  echelons  at  which  they  can  occur  within  the  model.  From 
the  table,  one  can  see  that  FORCEM  uses  units  for  many  things.  They  range  from 
the  usual  organization  of  men  and  equipment  (e.g.,  divisions),  to  representing 
installations  (e.g.,  prepositioning  of  materiel  configured  to  unit  sets 
[POMCUS]  "sites"  and  Equipment  Pool  "depots"),  and  even  convoys.  FORCEM's 
intelligence,  attrition,  and  effectiveness  procedures  were  designed  to  process 
only  units.  Non-unit  FORCEM  elements,  such  as  the  LOC  network,  are 
consequently  not  acquired  as  targets  or  attrited. 

9.  Simulated  Terr  n  and  Physical  Environment.  The  theater  representa¬ 
tion  in  FORCEM  is  composed  of  two  components:  the  terrain  grid;  and  the  LOC 
networks.  The  system  is  unique  to  FORCEM.  It  characterizes  an  area  cell  (the 
dimension  can  vary  --  early  FORCEM  applications  used  squares  with  30  km  sides, 
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recent  ones  use  10  km)  by  a  list  of  eight  directional  vectors  (north,  north¬ 
east,  east,  etc.)  indicating  the  predominant  type  of  terrain  encountered  along 
the  vector.  The  terrain  type  is  then  used  to  modify  the  inherent  movement  rate 
of  a  unit  as  it  moves  along  one  of  the  vectors.  The  LOC  networks  (road, 
canal,  and  railway)  are  implemented  in  a  similar  fashion  (i.e.,  by  directional 
vectors)  except  that  instead  of  terrain  types,  the  presence  of  road,  railroad, 
and  waterways  is  defined.  (See  Annex  E  for  a  more  detailed  discussion  of  these 
items.)  The  vector-based  terrain  representation  focuses  on  movement  rather 
than  unit  environment.  Terrain  appears  to  have  no  influence  on  unit  postures. 
So  any  inherent  advantage  in  holding  a  river  line  or  establishing  a  position  in 
terrain  favorable  to  the  defense  is  not  considered.  To  a  limired  degree, 
however,  a  tenuous  terrain  contribution  can  be  attributed  to  the  line  of  sight 
and  traff icability  considerations  inherent  in  the  combat  samples  generated  by 
COSAGE. 
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III.  ANALYSIS  OF  ENGINEER  REPRESENTATION 


10.  Theaterwide  Engineering.  In  determining  what  is  desired,  it  is 
useful  to  review  the  role  of  engineers  throughout  the  theater.  We  will  start 
with  a  broad  overview.  Figure  C-4  shows  the  priority  ranking  of  task  categor¬ 
ies  for  low- resolution  models  obtained  from  a  survey  of  army  modelers, 
engineers,  and  maneuver  commanders.  The  details  of  this  survey  are  discussed 
in  Annex  F.  To  help  analyze  the  theaterwide  task  requirements  for  FORCEM,  ESC 
used  this  task  ranking  as  a  starting  point  to  develop  a  more  detailed  list  of 
tasks  by  location  throughout  the  theater  (see  Figure  C-5) .  To  allow  a  cross¬ 
walk  between  the  priority  order  in  Figure  C-4  and  the  area  groupings  in  Figure 
C-5  each  task  category  in  Figure  C-4  has  been  given  a  letter  code;  and  the 
tasks  in  Figure  C-5  are  followed  by  the  letter  of  the  category  to  which  they 
belong.  The  actual  entries  in  the  table  show  the  types  of  engineer  tasks  that 
occur  within  the  applicable  functional  category.  This  list  establishes  the 
functions  that  are  candidates  for  inclusion  (either  explicitly  or  implicitly) 
in  FORCEM.  The  areas  establish  a  framework  that  is  directly  relatable  to  the 
scope  of  various  Army  models:  CASTFOREM  is  concerned  with  the  brigade  forward 
area;  COSAGE  is  division  sized;  VIC  looks  at  everything  up  through  the  corps; 
while  FORCEM's  scope  includes  the  entire  theater,  but  with  particular  attention 
to  the  communications  zone  (COMMZ) .  There  is  a  natural  bifurcation  of  engineer 
tasks  into  those  that  modify  or  deal  with  the  terrain,  and  those  that  deal  with 
facilities.  It  parallels  the  missions  that  engineers  have  in  CS  and  CSS. 
Engineer  work  in  the  brigade  and  division  areas,  i.e.,  the  forward  combat  zone 
(FCZ) ,  generally  deals  with  terrain  modifying  tasks.  (Note  that  we  will 
refrain  from  discussing  the  scores  of  actual  tasks  that  comprise  each  of  our 
listed  functional  categories.  They  are  fully  discussed  elsewhere .) ^  As  one 
moves  from  front  to  rear  in  the  theater,  the  focus  shifts  from  the  terrain  to 
the  facilities  necessary  to  sustain  the  war  effort.  In  fact,  the  repair,  main¬ 
tenance,  and  construction  categories  in  the  COMMZ  comprise  what  is  generally 
called  sustainment  engineering.  The  ability  of  CSS  units  to  conduct  rear  area 
sustainment  operations  as  well  as  move,  clothe,  and  shelter  troops,  is 

^Mobility,  FM  5-101  (January  1985);  Counter  Mobility ,  FM  5-102  (March 
1985);  Survivability,  FM  5-103  (June  1985);  General  Engineering,  draft,  FM  5- 
104  (April  1985)  . 


LOW -RESOLUTION  MODELS 


OVERALL  TASK  RANKING 


1 


Letter 

Code* 


Task  Categories  Sorted  in  Priority  Order 


Priority 
Ranking 
_ (%) 


Vital  Task  Croup 

A  Install  linear  obstacles  8.9 
B  Prepare  fighting  positions  for  direct- fire  systems  8.8 
C  Airfield  damage  repair  8.1 
D  Maintain  main  supply  routes  7.8 
E  Prepare  positions  for  indirect- fire  &  other  systems  6.9 
F  Port  &  waterfront  facilities  construction  &  repair  6.8 
G  Site  preparation  &  maintenance  for  CS  &  CSS  units  6.7 
H  Breach  obstacles  in  the  assault  6.5 
I  Rear  area  facility  rehabilitation  &  maintenance  6.4 


Critical  Task  Group 

J  Forward  airlanding  facility  preparation  &  maintenance 

K  Conduct  river  crossing  operations  in  the  assault 
L  Install  point  obstacles 

M  Pioneer  trail  preparation  &  maintenance 

Essential  Task  Group 

N  Improve  river  crossing  sites  for  follow-on  forces 
0  Improve  assault  breaches  for  follow-on  forces 

Necessary  Task  Group 
P  Other  (engineer  raids) 


6.1 

5.8 

5.6 

5.5 


4.7 

4.0 


1.2 


*The  letters  are  assigned  to  simplify  the  crosswalk  between  the 
task  categories  used  in  the  survey  covered  in  Annex  F  and  the  task 
break  down  discussed  in  this  annex. 


Figure  C-4 
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^Letters  in  parentheses  correspond  to  the  letter  codes  in  Figure  C-4. 


dependent  upon  engineer  support.  The  "ideal"  engineer  module  would  address 
all  the  listed  activities  to  simulate  the  breadth  and  amount  of  engineer  work. 
Such  an  "ideal"  version  is,  of  course,  realistically  unattainable  given  the 
limits  and  level  of  detail  of  a  theater  model.  The  challenge  then  is  to  adapt 
engineer  representational  needs  within  FORCEM's  present  design,  components, 
and  computational  limits . 

11.  Needs  of  the  analytic  community.  What  is  FORCEM's  purpose?  As  was 
indicated  previously,  FORCEM  was  designed  to  become  the  Army's  principal 
theater- level  war  game,  having  the  ability  to  test  the  adequacy  of  and 
identify  the  shortfalls  in  the  Army's  combat  and  support  mix.  While  it  has 
been  used  successfully  on  several  studies,  FORCEM  has  not  reached  the 
functionality  directed  by  AR  5-11.  Originally,  FORCEM  was  to  support  both 
capability  and  requirements  analyses,  relying  on  the  division/corps  results 
from  CORDIVEM.  At  this  time,  it  operates  as  a  capabilities  model  that  relies 
on  division- level  combat  samples  from  COSAGE,  and  on  FASTALS  to  round  out 
those  portions  of  the  force,  including  engineers,  which  are  not  represented  in 
FORCEM.  CAA  is  constantly  improving  FORCEM,  and  presumably  it  will  eventually 
attain  its  targeted  functionality.  Thus,  it  will  be  used  for  both  program  and 
budget  force  analyses  and  eventually  force  design.  At  that  time,  its  use  will 
run  the  full  gamut  of  studies  conducted  by  CAA:  OMNIBUS,  Total  Army  Analysis, 
and  war  materiels  estimation.  In  those  applications,  FORCEM  should  not  ignore 
the  important,  and  in  some  cases,  vital  role  of  engineers,  or  other  Army 
branches . 

12.  Compare  Actual  versus  Desired  Level  of  Engineer  Play.  CAA  does  not 
currently,  nor  is  it  likely  to  use,  the  engineer  submodel  developed  by  CERL. 
Thus  the  need  to  compare  engineer  representations  may  at  first  seem  academic, 
because  engineers  are  not  currently  represented  in  FORCEM.  Engineers  are, 
however,  treated  in  the  models  that  currently  supplement  FORCEM.  To  under¬ 
stand  where  engineer  play  would  fit,  it  is  important  to  compare  FORCEM's 
actual  and  desired  software  environments. 

a.  Present  Representation.  Figure  C-6  summarizes  where  and  which 
engineer  functional  groups  were  primarily  to  be  modeled  in  the  AMIP  and  how 
they  actually  are.  It  shows  that  not  only  are  engineers  not  being  played  in 
FORCEM,  but  they  are  also  underplayed  in  the  models  that  supplement  FORCEM, 
particularly  in  the  FCZ.  Of  the  many  engineer  tasks  comprising  CS ,  only 
minefields  are  included  within  COSAGE.  FASTALS  uses  allocation  rules  to 

C- 15 


« 


.1 


i 


f 


« 


J 


estimate  engineer  forces  at  corps  and  below.  Such  a  method  is,  however, 
divorced  from  the  actual  effects  these  forces  might  have  on  the  battlefield. 

Engineer  support  levels  in  the  COMMZ  fares  better  in  FASTALS ,  at  least  to  the  -j 

extent  that  they  are  based  on  estimated  requirements.  Engineer  COMMZ  workload 


OPERATIONAL  ENVIRONMENTS 
(Engineer  Task  Representation) 


Theoretical 

Current 

CORDIVEM 

FORCEM 

COSAGE 

FORCEM 

FASTALS 

Mobility 

X 

X1 

Counter- 

Mobility 

X 

X1 

X2 

Survivability 

X 

xl 

Sustainment  Engi¬ 
neering  (Division) 

X 

X1 

Sustainment  Engi¬ 
neering  (COMMZ) 

Repair 

X 

x3 

X4 

Maintenance 

X 

X4 

Construction 

X 

X4 

^-FORCEM  would  play  activities  that  are  in  the  corps  rear  (e.g.,  LOC 
bridging,  army  airfields,  digging  in  ADA  units,  etc.). 

2COSAGE  only  simulates  minefield  effects  (delay  and  attrition) . 
3FORCEM  engineer  logic  allows  repair  of  ports,  air  bases,  and  POMCUS 
sites,  but  CAA  has  elected  not  to  exercise  engineer  play. 

^See  discussion  of  FASTALS. 


Figure  C-6 

in  FASTALS  is  based  on  23  task  categories,  which  are  functions  of  13  workload 
parameters  (see  Figure  C-7) .  These  tasks,  however,  do  not  represent  all 
engineer  COMMZ  tasks.  It  is  difficult  to  distill  engineer's  varied  workload 
into  just  a  few  broad  parameters.  How  many  miles  of  road  or  railroad  are  "in 
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FASTALS  ENGINEER  WORKLOAD  PARAMETERS 


_ Workload  Parameter _ 

1  Miles  of  road* 

2  Miles  of  railroad* 

3  Miles  of  pipeline* 

4  Dry  cargo  &  unit  equipment 

through  port  per  day 

5  Dry  cargo  (Class  V)** 

6  Class  V  supplies  stored** 

7  Class  I  storedxx 

8  Class  III  stored 

9  EPWs 

10  US  Army  non-divisional 

population 

11  Replacements  thru 

camps/day 

12  Fixed  bed  requirements 

13  Manual  computation 


FASTALS  Task  (and  number') 

Repair  of  roads  (1) 

Repair  of  road  bridges  (2) 
Maintenance  of  roads  (20) 

Repair  of  railroads  (3) 

Repair  of  railroad  bridges  (4) 
Maintenance  of  railroads  (21) 

Repair  of  pipeline  (5) 
Maintenance  of  pipeline  (22) 

Repair  of  ports  (6) 


General  supply  storage  (10) 

Ammunition  storage  (11) 

Refrigerated  storage  (12) 

POL  (bulk)  storage  (13) 

POW  camps  (14) 

Administrative  space  (9) 
Troop  camps  (8) 

Dispensaries  &  clinics  (17) 
Maintenance  shops  (18) 
Replacement  camps  (19) 


Hospitals  (16) 

Repair  of  Army  airfields  (7) 


'k 

Miles  in  use 

1000  Short  Tons  supplies 


use?"  Are  only  major  routes  included,  or  all  routes?  Where  do  supply  class 
quantity  estimates  come  from?  While  the  process  that  arrives  at  these  values 
may  be  credible,  the  danger  of  using  too  simplistic  an  equation  jeopardizes 
the  correctness  of  the  estimate. 

b.  Implications.  The  omission  of  engineer  capabilities  and 
contributions  at  EAD  in  theater  level  wargames  at  CAA  has  ramifications 
throughout  the  Army.  Engineers  comprise  11  percent  of  the  total  Army  TOE 
structure.  Unlike  most  other  branches,  engineer  activities  range  from  the 
covering  force  areas,  to  the  ports  in  the  theater  rear.  Admittedly,  it  is 
difficult  to  model  the  effect  of  a  minefield,  or  the  result  of  not  doing  road 
maintenance.  History  is  too  replete,  however,  with  evidence  from  many 
quarters  showing  the  importance  of  such  tasks  and  the  often  critical  role 
engineers  play.  Accepting  the  contention  that  engineers  should  be  duly 
represented  in  FORCEM,  the  following  sections  show  several  specific  areas 
where  effort  should  be  directed. 

(1)  FORCEM  contains  code  for  COMMZ  engineer  repair  tasks  and 
engineer  units.  Up  to  now  that  capability  has  never  been  exercised  in  a 
study.  Nor  does  it  appear  that  the  effort  that  went  into  confecting  the 
existing  engineer  logic  was  anything  more  than  a  learning  experience.  The 
reasoi..  why  is  not  because  of  something  intrinsic  to  engineer,  but  because  the 
structures  used  were  inconsistent  with  the  rest  of  FORCEM.  This  lesson  must 
be  considered  when  developing  an  improvement  plan.  In  any  case,  the  result  is 
that  although  engineer  units  can  be  present  in  the  model,  they  are  not  and 
thus  don't  explicitly  effect  play  in  any  way. 

(2)  Although  engineers  at  EAC  are  not  played  in  FORCEM,  force 
planners  must  still  quantify  them.  FASTALS  currently  satisfies  this  need; 
however,  the  force  round  out  process's  use  of  a  few  general  workload  para¬ 
meters,  and  particularly  of  allocation  factors  and  set  asides,  diminishes  the 
dynamic  contribution  of  engineers.  Nor  does  it  indicate  what  the  effect  of 
non-support  means  to  the  successful  conduct  of  the  war.  Moreover,  FASTALS 
does  not  directly  consider  some  vital  engineer  tasks  that  have  important 
resource  and  force  effectiveness  impacts . 

(3)  FORCEM's  primary  area  of  interest  is  at  EACs .  As  said 
earlier,  to  be  able  to  concentrate  its  attention  there,  it  relies  on  combat 
samples  for  combat  results.  Initially,  FORCEM  was  to  depend  upon  CORDIVEM  for 
division  and  corps  information  on  combat  outcomes.  COSAGE  was  substituted  but 


only  operates  at  division- level ,  and  only  considers  one  engineer- related 
activity  --  minefields,  specified  by  predefined  locations  and  seemingly 
independent  of  engineer  troop  availability.  Setting  aside,  momentarily,  the 
questions  of  how  well  COSAGE  models  FCZ  engineer  tasks  and  FORCEM  (or  FASTALS) 
models  COMMZ  tasks,  there  is  a  gap  in  engineer  workload  representation  between 
COSAGE  and  FASTALS,  principally  in  defining  engineer  workload  for  engineer 
units  at  EAD.  This  omission  serves  to  ignore,  in  particular,  the  role  of 
engineer  corps  battalions  (doctrinally  having  as  many  as  three  battalions, 
over  2,000  non-divisional  engineer  troops ,  for  every  combat  division)  to 
effect  the  conduct  of  the  war.  First,  even  if  FORCEM' s  C^  logic  assigned 
corps  engineer  battalions  to  the  direct  support  of  a  division  (similar  to 
allocating  artillery  support),  which  it  does  not  do,  ATCAL's  evaluation  would 
be  unaffected.  And  secondly,  there  is  no  mechanism,  implicit  or  explicit, 
within  FORCEM  that  considers  engineer  activities  in  the  corps '  rear  area. 
Engineer  activities  in  that  area  have  a  direct  impact  on  ADA  survivability, 

POL  storage,  forward  aviation,  etc.  Presuming  availability  without  comparing 
engineer  requirements  and  capability  could  very  well  bias  results. 

(4)  The  critical  importance  of  sustaining  USAF  sortie  rates  in 
the  face  of  enemy  attacks  is  not  realistically  played  in  FORCEM.  Air  base 
damage  in  the  model  has  no  effect  on  air  base  operations;  and  USAF  personnel, 
in  particular  base  civil  engineers,  are  not  included.  A  US  Army  engineer  mis¬ 
sion  is  to  assist  USAF  engineers  when  damage  or  beddown  requirements  exceed 
USAF  capability.  The  beddown  task,  in  particular,  can  be  sizeable  depending 
upon  the  theater  being  played. 

(5)  Further  complicating  the  issue,  is  the  need  to  consider 

host-nation  engineer  support  (HNS).  Estimating  how  much  assistance  US  forces 

will  receive  from  indigenous  military  or  civilian  engineers  is  part  of  US 
1  ft 

military  planning.0  FASTALS  includes  an  estimate  of  HNS  in  determining  US 
engineer  requirements.  If  engineer  operations  are  injected  into  FORCEM,  then 
HNS  will  have  to  be  addressed  either  explicitly  or  implicitly. 

(6)  Since  FORCEM  is  a  symmetric  model,  the  lack  of  engineer 
play  applies  as  well  to  enemy  capability.  In  a  European  scenario,  PACT  forces 
do  not  have  to  worry  about  seaports  and  the  extended  oceanic  LOCs  that  con¬ 
front  the  US  or  North  Atlantic  Treaty  Organization  (NATO)  commander.  But  they 

l^Army  Force  Planning  Data  and  Assumptions ,  FY  1988-1997  (DA,  August  1987). 
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do  have  to  worry  about  keeping  their  air  bases  operational,  and  maintaining 
their  own  LOCs .  And  even  more  than  NATO,  they  must  worry  about  mobility  and 
sustaining  the  offensive  in  consonance  with  their  doctrine.  If  FORCEM  pro¬ 
fesses  to  emulate  an  air/land  battle  doctrine,  then  it  should  play  the  effects 
of  both  deep  attacks  and  the  enemy's  ability  to  contend  with  them. 

13.  Recommendations .  FORCEM  is  continually  evolving  and  moving  toward 
the  operational  capability  outlined  in  the  AMIP.  This  presents  somewhat  of  a 
problem  since,  to  a  degree,  FORCEM  is  a  moving  target.  Which  combat  sample 
generator  should  one  plan  around?  Should  it  be  the  limited,  division-level 
COSAGE  or  the  more  expansive,  corps-level  VIC  model?  Does  one  also  assume 
that  FASTALS '  tasks  will  eventually  be  brought  into  FORCEM?  And  most  impor¬ 
tantly,  will  CAA's  own  ongoing  development  of  FORCEM  make  any  engineer  code 
submissions  moot?  ESC  recognizes  these  concerns  and  has  adopted  an  approach 
which  looks  as  much  at  FORCEM  as  it  does  at  simulating  engineer  activities. 
Unlike  CERL's  focus,  which  appears  to  be  a  continuation  of  its  previous  FORCEM 
work,  ESC  has  chosen  to  frame  its  recommendations  in  more  systemic  terms, 
treating  the  model  as  an  environment  and  engineer  work  as  classes  of  tasks 
rather  than  many  isolated  pieces. ^  The  recommended  improvements  have  been 
divided  into  two  parts:  the  first  deals  with  features  that  must  be  added  to 
FORCEM  to  realistically  represent  engineers;  the  second  looks  at  several 
FORCEM  constructs  which,  if  changed,  would  greatly  influence  how  engineer 
enhancements  are  implemented.  ESC  believes  that  its  proposed  structural 
changes  to  the  model  would  enhance  FORCEM  as  well  as  facilitate  particular 
engineer- related  additions. 

a.  Engineer  enhancements.  Engineer  actions  have  several  dimen¬ 
sions.  Where  do  engineers  operate?  What  do  they  do?  Who  does  it?  What  is 


l^ESC's  findings  and  recommendations  essentially  corroborate  CERL's  views 
on  engineer  representation.  CERL  breaks  improvements  into  groups  of  tasks  to 
be  implemented  in  three  phases:  the  first  addresses  construction  and  repair 
at  installations  or  facilities  that  can  be  tied  to  either  FORCEM  units  or  the 
logistic  network  without  major  modifications;  second,  mobility,  counter¬ 
mobility,  and  survivability  tasks  would  be  introduced  into  the  corps  rear,  and 
direct  support  to  divisions  would  be  examined;  and  finally,  FASTALS  tasks  that 
were  not  addressed  in  the  prior  phases,  USAF  and  Army  emergency  repair 
missions,  and  hospital  support  would  all  be  included.  The  difference  between 
the  September  1987  and  December  1987  proposals  was  CERL's  own  concern  over  the 
relevancy  of  implementing  tasks  without  also  including  the  effects  of  their 
non-performance . 
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the  result?  These  questions  must  all  be  answered  in  the  model  if  it  is  to 
realistically  emulate  engineers.  For  our  purpose,  they  have  been  broken  into 
the  following  categories:  terrain,  installations,  tasks,  units,  and  effects. 

(1)  Terrain.  To  effectively  model  many  engineer  operations, 
there  must  be  a  realistic  treatment  of  terrain,  including  the  logistic  net¬ 
work.  Much  of  combat  engineer  support  involves  terrain  modification.  History 
shows  that  combat  results  are  inextricably  bound  to  the  terrain,  whether 
engineer  modified  or  not  (e.g.,  Kursk,  Monte  Casino,  North  Africa,  and  Market 
Garden) .  We  have  noted  that  COSAGE  division  samples  implicitly  include  mine¬ 
fields,  although  irrespective  of  engineer  capability  present  in  the  division 
or  corps.  Otherwise,  obstacle  and  barrier  systems,  whether  existing  or 
planned,  forward  or  rear,  are  not  included  in  FORCEM.  Terrain  as  a  whole  is 
essentially  a  non- factor,  beyond  influencing  movement.  The  combat  samples 
generated  by  COSAGE  use  a  statistically  "averaged"  terrain  sample,  which  is 
primarily  concerned  with  representing  line-of -sight .  On  the  other  hand,  even 
if  terrain  did  affect  unit  postures  or  combat  results,  FORCEM' s  limited  ter¬ 
rain  representation  could  not  supply  meaningful  input.  Each  terrain  vector  in 
FORCEM  is  coded  according  to  a  dominant  terrain  feature  which  is  used  pri¬ 
marily  as  an  index  to  a  movement  rate  table.  The  LOC  networks  are  similarly 
represented.  Enhancements  are  necessary  to  represent  the  engineer  activities 
at  EAD,  associated  with  movement.  At  the  very  least,  modifications,  both 
temporary  (simulating  minefield  creation  and  clearing)  and  permanent  (destruc¬ 
tion  of  a  major  bridge,  upgrade  of  a  road  to  MSR  standard),  to  vector  and 
network  members  (to  effect  movement  rates)  must  be  supported.  Capacitating 
the  LOC  networks  should  also  be  considered  in  order  to  better  estimate  the 
effects  of  damage  and  maintenance  needs  as  well  as  bottlenecks  and  overload. 
These  changes  will  not  effect  combat  engineering  (unfortunately  it  appears 
that  for  as  long  as  FORCEM  is  dependent  on  COSAGE  the  ability  of  engineers  to 
influence  the  division  battlefield  will  be  negligible) ,  but  they  will  at  least 
better  reflect  the  important  engineer  support  of  LOCs  and  movement  in  general. 

(2)  Installations.  With  the  bulk  of  COMMZ  engineering  con¬ 
cerned  with  facilities,  FORCEM  needs  to  represent  the  sustainment  base,  and 
operations  associated  with  it.  Currently,  FORCEM  models  three  types  of 
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installations:  ports,  air  bases,  and  POMCUS  sites. It  does  not,  however, 

adequately  represent  operations  at  those  installations.  Nor  can  it  be  said 
that  the  three  adequately  describe  the  entire  sustainment  base.  Units  are 
played  in  FORCEM  (such  as  personnel  and  supply  pools)  which  imply  the  exis¬ 
tence  of  depots,  troop  camps,  maintenance  shops,  and  hospitals,  but  there  are 
no  installations.  Since  the  units  and  the  functions  they  perform  implicitly 
rely  on  the  existence  of  supporting  installation  and  facilities  they  should  be 
included  in  the  model.  The  presence  of,  or  requirement  for,  an  installation 
might  be  dictated  by  several  different  means:  as  a  preexisting  asset,  by 
external  direction  (e.g.,  logistics-over-the-shore  operations  [LOTS]),  or  as 
an  internal  event  (movement  of  a  support  command  might  demand  a  new  depot  to 
be  built) .  The  size  of  the  installation  can  probably  be  expressed  in  either 
absolute  terms  (square  feet  or  barrels  of  storage)  or  using  a  single  surrogate 
measure  such  as  beds,  number  of  troops,  or  tons  of  storage.  Engineer  con¬ 
struction,  repair,  and  possibly  even  maintenance  tasks  could  be  associated 
with  installation  types  through  tables  or  piecewise  continuous  curves.  With 
installations  explicitly  represented,  damage  could  be  calculated  explicitly 
rather  than  by  using  unit  casualties  as  a  surrogate  measure.  This  would  make 
damage  a  function  of  installation,  characteristics  (not  of  the  units  that  hap¬ 
pen  to  be  there)  and  threat  capability.  It  would  also  better  support  engineer 
repair  workload  and  resultant  installation  capability  estimates.  Ideally, 
installations  would  be  best  served  if  defined  as  separate  entity  classes, 
rather  than  contorting  them  into  the  unit  framework  (see  section  on  FORCEM 
improvements) . 

(3)  Engineer  tasks.  Better  representation  of  terrain  and 
installations  will  provide  the  foundation  for  identifying  and  quantifying 
engineer  workload.  First,  the  representation  of  tasks  should  be  standardized. 
Normally,  engineers  express  resource  requirements  for  terrain  modifying  tasks 
(including  bridging  and  minefield  laying)  in  terms  of  squad  and  equipment 


on 

The  engineer  definition  of  an  installation  is  "...a  group  of  facilities 
in  the  same  vicinity  that  supports  particular  functions..."  ( AFCS  Design 
Manual  [US  Army  Engineer  Division,  HNDM- 1110- 1 -4 ,  1  September  1980],  p.  1-3). 
Now  there  is  only  one  type  of  facility  explicitly  represented  in  FORCEM  -- 
runways.  Realistically,  facilities  are  probably  below  FORCEM's  resolution; 
representing  installations  and  LOCs  is  more  in  keeping  with  the  model's 
current  level  of  detail. 
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hours.  ^  Facility,  i.e.,  installation- related  tasks,  generally  use  work  esti¬ 
mates  derived  from  the  several  services'  facility  component  systems, ^2  which 
express  construction,  repair,  and  maintenance  tasks  in  terms  of  average  daily 
hours  of  required  horizontal,  vertical,  and  general  engineer  skills. ^  While 
the  skill  and  equipment  distinctions  are  real,  they  introduce  resolution 
inconsistent  with  the  intended  level  of  detail  in  FORCEM.  More  appropriate 
would  be  task  requirements  that  remain  related  to  the  magnitude  of  the 
activity  or  size  of  the  installation,  but  expressed  in  terms  of  amount  (hours 
per  cycle)  and  duration  (number  of  cycles)  of  engineer  support.  A  second 
component  of  task  representation  is  identification.  Rather  than  have  engi¬ 
neers  search  for  jobs,  it  seems  more  efficient  for  a  task,  whether  digging  in 
an  ADA  unit  or  repairing  an  air  base,  to  be  identified  at  the  time  the  event 
occurs,  and  to  be  placed  in  the  task  queue  of  an  engineer  or  unit.  For  the 
purpose  of  discussing  particular  workload  categories,  engineer  tasks  have  been 
divided  into  combat  and  COMMZ  area  groups.  An  earlier  discussion  of  engineer 
tasks  indicated  that  this  is  but  one  of  several  different  ways  tasks  could  be 
partitioned. 

(a)  Combat  zone.  FORCEM' s  reliance  on  division  combat 
samples  means  that  most  deficiencies  in  combat  engineer  representation  cannot 
be  mitigated  by  making  changes  to  FORCEM  itself.  Engineer  improvements  within 
FORCEM  will  not  reach  the  FCZ  area,  where  results  from  COSAGE  are  currently 
used.  If  it  is  accepted  that  engineers  should  be  one  of  the  factors  in  the 
combat  samples,  the  question  then  becomes  how  this  can  be  accomplished. 

Besides  modifying  COSAGE,  there  is  another  alternative  --  VIC.  This  model  is 
now  on  CAA's  VAX  8600,  and  the  agency  is  studying  the  model  and  the  prospects 
of  using  it  in  lieu  of  COSAGE.  Engineers  are  explicitly  played  in  VIC,  and 
improvements  and  additions  are  being  pursued. ^  If  CAA's  evaluation  indicates 
VIC  will  become  the  combat  sample  generator,  then  improving  engineer  play  in 
COSAGE  may  become  a  moot  issue.  On  the  other  hand,  since  FORCEM  has  been 
designed  around  divisional  combat,  it  seems  likely  that  even  if  VIC,  despite 
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1986)  . 
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Engineer  Assessment ,  Korea:  Forward  Combat  Zone  Analysis  (ESC,  July 
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Army  Facility  Component  System,  Temperate  Zone  (TM  5-301-1). 

Engineer  Assessment ,  Korea:  Communications  Zone  Analysis  (ESC,  Septem¬ 


ber  1987) . 
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See  Annex  B,  this  report. 
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Its  more  expansive  corps -level  scope,  succeeds  COSAGE,  samples  will  remain 
structured  around  divisional  play.  While  it  makes  sense  to  defer  FCZ 
consideration  until  VIC  arrives,  combat-related  tasks  arising  in  the  corps 
rear  can,  and  should  be  added  to  FORCEM  now.  Combat  engineering  tasks  of 
mobility,  countermobility,  and  survivability  occur  at  EAD.  Typical  tasks 
include:  digging  in  air  defense  artillery  (ADA)  units,  rear  obstacle  prepara¬ 

tions  for  the  defense,  obstacle  clearing  for  the  offense,  LOC  repair,  and 
forward  aviation  support.  Note  that  these  tasks  involve  both  terrain  and 
installation  related  tasks.  Some  of  the  tasks  can  be  readily  tied  to  events 
presently  within  the  model.  An  example  is  the  need  to  prepare  positions  for 
an  ADA  unit.  Tasks  such  as  tactical  airfield  construction  and  constructing 
defensive  obstacles,  however,  appear  to  be  beyond  the  present  decisionmaking 
ability  of  FORCEM,  and  would  necessarily  be  the  result  of  offline  analysis. 

(b)  COMMZ  support.  At  the  very  least,  FORCEM' s  engineer 
representation  should  adequately  simulate  operations  at  the  level  of  par¬ 
ticular  emphasis  in  the  model  --  EACs .  Engineer  tasks  at  EAC  primarily 
support  the  construction,  repair,  and  maintenance  of  the  sustainment  base. 
Realistically,  representing  these  tasks  involve  several  needs:  determining 
installation  and  facility  requirements,  calculating  construction  resources, 
estimating  damage  and  maintenance,  and  assessing  the  impact  of  reduced  or 
inadequate  installation  facilities.  This  is  not  an  easy  problem  and  is  large 
enough  to  require  substantial  models  of  its  own.^  Within  FORCEM,  engineer 
tasks  in  the  COMMZ  will  naturally  be  associated  with  installation  needs.  As 
with  CS  taskings ,  it  will  probably  be  easier  to  identify  the  task,  in  some 
form,  at  the  change  of  state  time  by  logic  that  applies  to  that  class  of 
installations.  The  notice  could  then  be  either  kept  at  the  installation  or 
passed  to  a  unit. 

(4)  Engineer  units.  Engineer  unit  configuration  is  dictated  by 
the  structure  permitted  by  FORCEM  and  the  representation  of  engineer  tasks. 
Engineer  units  vary  widely  in  specialty,  capability,  and  composition.  Some 
units  have  very  definite  tasks  associated  with  them.  A  port  construction 
company  operates  essentially  at  or  near  the  shore  of  a  port  or  LOTS  site, 
while  a  pipeline  company  is  specially  trained  and  equipped  to  pursue  its 
trade.  Realistically,  the  level  of  detail  involved  in  modeling  such  special 
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Simulated  Engineer  Assessment  of  the  COMMZ  (SEAC)  (ESC,  June  1988). 


unit  capabilities  is  not  commensurate  with  the  rest  of  FORCEM.  Nor  are  the 
common  expressions  of  engineer  unit  capabilities  (i.e.,  squad  and  equipment 
hours  for  combat  tasks  and  skill  hours  for  facility-related  work).  In  keeping 
uith  the  proposed  FORCEM  task  definitions  in  terms  of  man-hours,  engineer  unit 
capability  also  should  be  expressed  as  the  number  of  hours  available  during  a 
FORCEM  time  slice  (currently  12  hours) .  This  also  would  satisfy  the  second 
predicator  of  engineer  unit  structure  within  FORCEM  --  CAA's  present  or  future 
(see  next  section)  definition  of  units. 

(5)  Effects.  The  effects  of  accomplishing  or  not  accomplishing 
engineer  tasks  are  as  fundamental  to  representing  engineers  as  is  the  inclu¬ 
sion  of  engineer  units  or  the  identification  of  installations  and  terrain 
associated  tasks.  Engineer  operations  should  not  be  isolated  from  the  other 
processes  within  FORCEM.  The  reason  why  there  is  an  Engineer  Management 
Improvement  Frogram  (EMIP)  is  that  engineer  contributions  in  the  FCZ  and  COMMZ 
have  heretofore  gone  unrecognized  in  combat  models.  This  is  undoubtedly 
because  of  both  the  focus  on  weapon  systems  and  strictly  combat  forces  and  to 
a  degree  on  the  fact  that  engineer  effects  do  not  fall  into  one  neat  little 
package.  Engineers  can  slow  up  the  enemy  as  well  as  destroy  them.  They  can 
permit  friendly  forces  to  move  faster  and  to  places  otherwise  denied  to  them. 
Figure  C-8  attempts  to  show  the  disparate  candidates  an  engineer  modeler  could 
use  for  measures  of  effectiveness  (MOEs)  for  various  tasks.  The  effects  in 
the  table  are  not  even  meant  to  be  exclusive;  a  minefield  can  be  used  as  much 
to  delay  or  reduce  movement,  as  to  directly  kill  enemy  vehicles  and  personnel. 
The  effects  are  even  harder  to  quantify.  Nonetheless,  a  strict  criteria  for 
including  engineer  tasks  should  be  that  an  MOE  also  be  included.  Data  and 
logic  that  do  not  influence  the  outcome  of  the  simulation  are  mere  clutter  and 
should  be  avoided.  Representing  effects,  however,  means  that  other  FORCEM 
processes  and  elements  must  reflect  the  impact  of  inadequate  engineer  support. 
For  example,  air  base  sortie  generation  and  LOC  capacity  are  presently 
unaffected  by  model  events.  To  implement  the  mechanism  to  allow  installation 
facility  status  to  influence  their  operations,  new  logic  and  data  would  need 
to  be  added,  not  to  engineer  units  or  tasks,  but  to  air  bases  or  LOC  routines 
and  data.  Classification  of  initial  damage  repair  must  be  addressed  (all 


SAMPLE  OF  ENGINEER  ACTIVITIES  AND  ASSOCIATED  EFFECTS 


Area 

Engineer  Activitv 

MOEs 

FCZ 

minefield  emplacement 
increase  friendly  mobility 
decrease  enemy's  mobility 
build  defensive  positions 

casualties 

movement  rate 

movement  rate 

casualties 

Corps 

Rear 

improve  survivability 
logistic  network 
prepare  obstacles 

casualties 
supply  capacity 
movement  rates 

COMMZ 

build/repair  ports 
build/repair  air  bases 
pipeline  construction 
maintain  LOCs 

resupply  capacity 
sortie  rates 
capacity 
capacity 

Figure  C-8 


repairs  at  an  air  base  need  not  be  made  to  restore  maximum  operational 
capability)  as  well  as  its  effect  on  reducing  an  installation's  operational 
capability . 

b.  FORCEM  improvements.  Designing  and  implementing  code  which  will 
achieve  much  of  what  has  been  described,  is  not  a  trivial  undertaking. 

Changing  any  model,  much  less  one  as  complex  as  FORCEM,  is  usually  easier  said 
than  done.  During  its  review,  however,  ESC  noted  that  the  form  of  several 
major  FORCEM  elements  and  conventions,  greatly  determine  how  engineer  opera¬ 
tions  will  or  can  be  represented.  In  their  present  forms,  these  features  will 
probably  require  the  engineer  modeler  to  use  various  indirect  means  to  achieve 
results.  Since  FORCEM  is  continually  being  improved,  however,  it  should  be 
possible  to  retool  portions  of  the  model.  ESC  proposes  two  FORCEM  improve¬ 
ments  that  would  not  only  facilitate  engineer  modeling,  but  also  have  value  to 
processes  throughout  the  model. 

(1)  Terrain.  ESC  has  indicated  that  FORCEM' s  terrain  represen¬ 
tation  would  have  to  be  augmented  to  support  representation  of  some  engineer 
tasks  and  associated  effects.  The  present  terrain  structure  essentially 
defines  several  networks  which  facilitate  movement  calculations.  Internally 
it  is  represented  by  several  two-dimensional  integer  arrays;  array  cells 
contain  the  vector  characteristics  stored  in  packed  format  (i.e.,  the  eight 
directional  codes  are  stored  as  an  eight  digit  number  with  the  first  digit 
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associated  with  northeast,  the  second  with  east,  etc.).  No  other  data  is 
endemic  to  a  grid  cell.  A  cell  appears  not  to  know  that  it  contains  air  bases 
or  ports.  To  find  out  what  units  (remember  that  ports  are  pseudo-units)  might 
be  in  a  cell,  a  unit  list  must  be  searched  with  each  unit's  location  compared 
against  the  cell's  to  see  if  it  is  in  that  cell.  This  is  efficient  as  long  as 
the  lists  remain  relatively  short.  If  obstacles,  LOC  capacities  and  damage, 
and  installation  data  are  all  placed  in  such  lists,  the  length  of  the  list  and 
therefore  the  processing  time  could  increase  dramatically.  ESC  is  concerned 
that  if  the  engineer  submodel  is  perceived  to  take  too  much  time  or  space, 
that  it  runs  the  risk  of  being  deactivated,  as  have  other  attempts  to  model 
engineers.  Although  CAA  has  no  plans  to  change  the  map  square,  vector-based 
terrain  representation,  ESC  feels  that  FORCEM's  terrain  representation  should 
be  enriched  to  better  support  terrain  related  actions.  A  viable  alternative 
might  be  to  make  it  entity-based .  This  would  enable  significant  physical  and 
man-made  terrain  features  as  well  as  units,  installations,  LOCs  (including 
pipelines),  obstacles,  and  other  pertinent  data  to  be  directly  associated  with 
a  cell.  The  drawbacks  are  increased  memory  requirements  and  the  need  to  make 
modifications,  some  significant,  to  existing  routines.  The  advantages  are  a 
unified  terrain  structure,  improved  means  of  inserting,  removing,  or  locating 
objects  in  a  cell,  and  more  realistic  procedures  and  effects  (engineer  opera¬ 
tions,  combat  attrition  evaluation,  target  acquisition,  intelligence,  chemi¬ 
cal,  nuclear,  etc.). 

(2)  Units.  The  FORCEM  "unit"  stricture  should  be  reduced.  In 
trying  to  be  everything  to  every  element  in  as  large  a  model  as  FORCEM,  the 
unit  has  accumulated  overhead  that  instead  of  supporting  enhancements,  impedes 
them.  Adding  a  new  model  element  that  has  people,  assets,  or  can  be  targeted, 
means  it  has  to  be  a  unit  and  have  the  same  attributes  that  every  other  unit 
has.  If  it  requires  a  new  attribute,  then  all  other  units  acquire  it  as  well. 
This  has  become  inefficient  and  monolithic . ^6  (A  more  efficient  and  powerful 
means  to  accomplish  the  intent  of  the  unit  is  found  in  the  hierarchical  data 


^An  example  is  aptly  illustrated  by  CAA's  rejection  of  CERL's  engineer 
module.  In  trying  to  fit  its  design  into  FORCEM,  CERL  used  the  attribute  list 
not  for  equipment  but  for  subordinate  units.  Since  SIMSCRIPT  does  not 
identify  data  typing  inconsistencies,  CERL's  artifice  guaranteed  runtime 
errors.  With  all  entities  accessible  to  all  procedures,  changes  must  be 
reviewed  across  the  entire  model. 
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structure,  common  to  object-oriented  languages,  which  provides  a  means  to 
selectively  combine  general  and  specific  entity  attributes  and  procedures . ^7 ) 
While  increasing  the  number  of  different  model  element  types  could  require 
associated  changes  in  some  processes  (targeting  and  attrition  among  others), 
the  looser  coupling  could  make  model  additions  and  modifications  easier. 

c.  Summary.  The  previous  paragraphs  have  described  the  general 
requirements  for  modeling  engineers  in  FORCEM.  Figure  C-9  summarizes  the 
tasks,  FORCEM  elements,  and  effects  that  comprise  the  engineer  modeling  pro¬ 
gram.  The  first  task,  improving  combat  engineering,  involves  FORCEM  only  to 
the  degree  that  an  improved  combat  sample  generator  would  accept  terrain  and 
engineer  parameters.  The  next  three  tasks  are  associated  with  activities  in 
the  corps  rear  area.  The  remaining  tasks,  largely  occur  in  the  COMMZ,  but, 
depending  on  actual  installation  location,  could  fall  within  corps  boundaries. 
Other  than  grouping  the  tasks  loosely  according  to  theater  area,  there  is  no 
other  meaning  to  be  ascribed  to  the  order  of  the  tasks  in  the  table.  The 
reason  for  this  is  the  mutuality  of  elements  and  tasks.  If  FORCEM' s  terrain 
representation  is  being  changed  to  accommodate  more  realistic  LOC  play,  how 
reserve  targets  might  be  implemented  should  also  be  considered.  This  is 
because  both  deal  with  the  terrain  and  movement  effects.  Similarly,  exploring 
better  representation  of  installations  effects  many  of  the  listed  tasks. 

Rather  than  looking  first  at  improving  port  representation,  and  then  at  supply 
depots,  the  modeler  should  be  looking  at  the  characteristics  all  installations 
have  in  common,  and  the  specific  features  that  sets  them  apart.  A  well 
structured  solution  will  ultimately  be  more  efficient  and  adaptable,  than 
something  designed  piecemeal.  Thus  the  entries  in  Figure  C-9  represent  an 
agenda,  rather  than  a  step-by-step  approach.  Some  changes,  although  viewed 
necessary,  are  dependent  on  things  beyond  the  control  of  the  engineer  modeler. 
If  VIC  were  not  to  replace  COSAGE,  then  representing  engineer  support  to 
division  combat  would  not  improve.  If  the  impact  and  cost  of  changing  terrain 
and  LOC  network  representation  in  FORCEM  is  prohibitive,  then  associated 
engineer  tasks  will  have  to  use  less  satisfying  indirect  means. 


^Two  examples  of  which  are  ADA:  ADA  Programming  Language  (ANSI/MIL- STD - 
1815A,  22  January  1983);  and  SIMULA  (Franta,  W.  E.,  The  Process  View  of 
Simulation,  North-Holland  1977). 


Engineer  Task  FORCEM  Element  or  Routine  Modeled  Effects 
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Included  for  FASTALS  compatibility. 


IV.  ANALYSIS  OF  MODIFICATIONS 


14.  Modeling  Approach.  The  design  of  a  new  engineer  sub-model  is 
largely  constrained  by  the  existing  design  of  FORCEM.  Only  if  the  optional 
FORCEM  improvements  that  ESC  identified  were  adopted,  would  a  great  deal  of 
flexibility  be  gained.  The  specification  and  design  of  a  new  engineer  sub¬ 
model  must  therefore  balance  the  constraints  imposed  by  the  implementor/manager 
(CAA)  and  the  interests  of  the  users  (both  force  designers  and  the  engineer 
community).  Structuring,  simplifying,  shifting  (i.e.,  to  another  model),  and 
substituting  are  activities  performed  by  modelers  to  make  a  problem  tractable. 
There  is  no  one  solution.  But  a  solution  that  is  never  perfected  (i.e.,  never 
becoming  a  standard  FORCEM  feature),  should  not  be  allowed  to  happen.  As  to 
what  programming  approach  will  be  adopted  in  a  FORCEM  engineer  submodel,  that 
should  be  left  to  the  developer,  although  always  subject  to  the  conventions 
used  in  FORCEM.  While  the  engineer  modeler  should  have  some  latitude,  there 
are  several  points  that  do  need  to  be  offered  as  guidance. 

a.  Capability  v.  requirements.  As  stated  earlier,  FORCEM  presently 
operates  as  a  capability  model,  although  its  future  ability  to  run  as  a 
requirements  model  has  not  been  dismissed.  How  requirements  might  be  handled 
remains  to  be  solved.  Rather  than  speculate  on  any  future  undefined  feature, 
the  engineer  modeler  should  concentrate  design  efforts  for  the  present  environ¬ 
ment  . 

b.  Implicit  v.  explicit.  Tasks,  engineer  capabilities,  and  effects 
can  all  be  represented  in  varying  levels  of  detail  and  form.  Implicit  treat¬ 
ment  very  often  is  a  euphemism  for  a  simplified,  offline,  or  surrogate  treat¬ 
ment.  An  explicit  element  is  just  that  --a  model  process,  datum,  or  event 
that  is  particularized.  Ideally  one  would  like  to  make  everything  explicit. 

The  ability  to  do  so  and  the  benefits  gained,  however,  often  say  otherwise.  To 
do  what  it  does,  FORCEM  blends  both  modes.  Combat,  for  example,  is  implicitly 
accomplished  using  ATCAL  to  extrapolate  among  different  COSAGE  results.  One 
must  be  wary,  however,  when  implicit  is  used  to  ignore  problem  aspects.  The 
engineer  modeler  should  start  with  the  idea  that  everything  should  be  explicit, 
but  be  prepared  to  consider  implicit  representation  depending  upon  circum¬ 
stances  . 

c.  Task  origination.  A  follow-on  to  the  previous  paragraph  is  the 
question  of  how  special  engineer  jobs  are  introduced.  Unlike  tasks  that,  at 


least  conceptually  will  be  requested  by  existing  FORCEM  elements,  such  as 
digging  in  an  ADA  unit,  or  implied  by  doctrine,  like  assigning  a  Direct  Support 
mission  to  an  engineer  battalion,  some  special  engineering  projects,  while 
identified  by  the  operations  plan,  have  no  triggering  event.  Emplacing  rear 
area  obstacles,  building  LOTS  and  air  base  facilities,  and  constructing  a 
pipeline  are  examples  of  such  projects.  A  separate  event  stream  and  routine 
are  necessary  to  create  the  special  project  and  follow  its  construction  until 
it  becomes  viable. 

d.  Prioritization.  Expecting  that  there  will  be  periods  when 
engineer  capability  is  insufficient  to  meet  demand,  there  should  be  a  mechanism 
in  place  to  categorize  work  into  priorities.  This  could  be  done  by  using 
decision  rules  similar  to  other  resource  allocation  processes  within  FORCEM, 
but  may  be  more  simply  accomplished  by  using  priority  assignments.  This  would 
simulate  the  action  of  engineer  planners  in  working  with  scarce  resources.  In 
fact,  at  the  installation  level,  work  might  well  be  stratified  according  to 
importance,  and  the  capability  of  the  installation  should  be  adjusted  according 
to  what  work  can  be  accomplished. 

e.  Guidance.  To  reduce  the  danger  of  being  used  inappropriately, 
and  to  avoid  later  criticism,  a  certain  level  of  modeling  discipline  must  be 
stipulated  and  maintained.  Too  often  models  are  developed,  but  over  time 
become  far  removed  from  the  original  designers.  Whoever  implements  the  new 
engineer  submodel  should  not  only  develop  code  and  identify  data,  but  also 
prepare  a  user's  guide  that  cross-references  the  structure  and  data  of  FORCEM 
that  directly  and  indirectly  affects  engineer  play. 

f.  Interpretation.  Until  the  phased  development  runs  its  course, 
engineers  will  not  be  fully  represented  in  FORCEM.  The  units  and  their  capa¬ 
bilities,  as  the  easiest  items  to  implement,  might  all  be  present,  but  the 
tasks  and  effects  that  they  will  accomplish  and  create  respectively,  probably 
will  not.  Thus  engineer  and  force  planners  should  be  cognizant  of  different 
mixes  of  workload  and  capabilities  and  not  assume  that  the  model  improvements 
are  in  locked  step.  The  underplay  of  engineer  work  could  overstate  engineer 
capability.  Any  analysis  should  either  identify  this  possibility,  or  actually 
withhold  engineer  units  that  would  be  dedicated  to  absent  task  workloads. 

15.  Ease  of  Modeling.  The  "stillbirth"  of  CERL's  engineer  model  for 
FORCEM,  illustrates  that  changes  or  enhancements  to  FORCEM  may  not  be  facile. 
Modifications  must  be  examined  across  the  entire  model  to  understand  possible 


impacts  and  unforeseen  effects.  (SIMSCRIPT's  lack  of  strong  typing,  e.g.,  its 
inability  to  identify  incorrect  use  of  pointer  variables,  is  a  potential  trap 
for  novice  and  expert  programmers  alike.)  Attaining  adequate  knowledge  of 
FORCEM  requires  a  considerable  start-up  investment,  especially  for  someone 
outside  of  CAA's  development  team.  In  view  of  this,  new  software  for  FORCEM 
should  be  cleared  with  CAA  at  every  stage  of  its  development,  since  the 
implications  of  adding  or  changing  code  or  data  may  not  be  evident. 

16.  Resources  Required.  Because  the  engineer  modeler  will  need  to 
become  somewhat  of  a  FORCEM  expert,  the  time  to  develop  and  implement  a  working 
engineer  submodel  will  take  somewhat  longer  than  if  he  were  developing  a  stand 
alone  module  of  comparable  size.  ESC  estimates  that  one  accomplished  SIMSCRIPT 
programmer/analyst  should  be  able  to  research,  implement,  and  document  the 
engineer  model  in  18-24  months.  If,  for  example,  CERL  was  given  the  job,  one 
would  expect  that  its  familiarity  with  FORCEM  would  place  it  at  the  lower  end 
of  the  range.  In  addition,  but  concurrent  with  code  development,  would  be  a  6- 
to  12-month  analysis  of  data  requirements.  This  would  quantify  engineer  unit 
capability,  task  resource  requirements,  installation  facility  cross  sections, 
installation  and  LOC  damage  and  maintenance  factors,  and  corresponding  data  for 
enemy  engineer  operations.  Not  addressed  in  these  figures  is  any  effort  CAA 
might  expend  in  modifying  FORCEM,  i.e.  changing  unit  or  terrain  representa¬ 
tions,  or  switching  from  COSAGE  to  VIC.  Proposed  changes  to  non-engineer 
routines  and  entities  probably  would  not  be  done  by  the  engineer  modeler. 
Whether  CAA  would  do  it  in-house  or  through  outside  parties,  would  be  its 
prerogative.  If  FORCEM  improvement  options  were  pursued,  the  engineer 
timetable  would  necessarily  be  effected,  not  because  it  would  take  more  effort 
to  model  engineers,  but  because  of  waiting  for  the  modifications  to  finalize. 
Resources  to  convert  and  link  VIC  are  also  outside  engineer  modeling,  despite 
having  potentially  great  impact  on  combat  engineering.  Exploiting  VIC  engineer 
capability  would,  however,  mean  that  decision  logic  allocating  corps  engineer 
assets  would  have  to  be  included  in  FORCEM,  whereas  such  code  is  presently 
absent  and  would  be  superfluous  with  combat  samples  from  COSAGE. 

17.  Impact  on  FORCEM.  The  surest  result  of  the  proposals  is  that  the 
model  will  require  more  memory,  and  take  longer  to  execute.  Truthfully,  it  is 
difficult  to  predict  how  much  longer  a  model,  as  large  and  complex  as  FORCEM, 
will  run  if  non- trivial  changes  are  made.  It  is  not  like  doubling  the  dimen¬ 
sion  of  an  array  in  a  matrix  multiplication  program  and  estimating  that  it  will 


now  take  four  times  longer  to  run.  A  simulation  program  will  be  different  for 
each  data  and  event  set.  Since  the  engineer  submodel  will  be  adding  data, 
introducing  new  code,  and  effecting  the  conduct  of  other  existing  routines  and 
entities,  it  will  mean  FORCEM  has  more  objects  to  create  and  manage,  more 
processes  to  invoke,  and  more  decision  paths  to  follow. 

18.  Conclusions .  Engineer  contributions  on  the  battlefield  and  through¬ 
out  a  theater  are  many  and  diverse.  Those  contributions  are  currently  not 
being  represented  in  FORCEM,  although  under  the  AMIP  charter  and  as  the  Army's 
principal  theaterwide  model,  they  should  be.  FORCEM' s  special  emphasis  on 
simulating  activities  and  effects  at  EAC,  should  include  a  minimum  COMMZ 
engineering  representation.  Considering  the  role  of  theater  wargames  in  force 
planning  and  programming,  it  is  apparent  why  engineers  seek  equitable 
representation.  While  the  sheer  variety  of  engineer  activities  does  present 
certain  implementation  problems,  they  can  be  modeled.  In  preparing  its 
recommendations,  ESC  compared  a  list  of  engineer  activities  with  both  present 
and  future  FORCEM  environments,  to  identify  inadequacies .  The  result  is  a  list 
of  enhancements  (see  Figure  C-9)  that  will  serve  as  the  basis  for  improved 
representation  of  engineers  in  FORCEM.  Figure  C-10  presents  the  range  of 
possible  EMIP  strategies  for  FORCEM.  The  options  run  the  gamut  from  doing 
nothing,  to  creating  a  new  theater  model  (i.e.,  making  it  the  be  all 
requirements  and  capabilities  model,  subsuming  the  functions  of  both  FORCEM  and 
FASTALS).  The  extreme  cases  are  of  course  undesirable  and  unlikely, 
respectively.  Setting  them  aside  leaves  us  with  three  plausible  approaches. 
Option  2  simply  trades  VIC's  better  representation  of  engineer  capability  for 
COSAGE's.  Since  CAA  intends  to  install  VIC  in  Bethesda,  this  change  appears  to 
be  a  tri-'or'  adjustment  in  FORCEM  to  take  advantage  of  VIC's  more  detailed 

division  play  (including  engineers  and  terrain)  should  not  be  major.  Although 
beneficial  to  engineer  combat  play,  switching  to  VIC  does  nothing  for  engineers 
at  EAD .  FASTALS,  as  indicated,  is  still  on  line,  but  as  a  requirements  model 
it  does  not  measure  the  contribution  or  impact  of  engineers.  Option  3,  like 
option  2,  includes  VIC,  but  both  models  incorporate  engineer  enhancements.^® 

ESC  uses  enhancements  and  improvements  in  the  same  manner  that  it  has  through¬ 
out  this  annex;  enhancements  are  new  model  features  or  capabilities,  while 
improvements  are  changes  to  existing  model  structures  or  processes. 

2®See  Annex  B  of  this  report  regarding  VIC. 
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Enhancements  to  FORCEM  would  represent  engineer  units,  workload  tasks,  and  the 
data  and  routines  necessary  to  measure  engineer  effects. ^  Option  4  adds  FORCEM 
improvements  to  Option  3.  The  FORCEM  improvements  outlined  by  ESC  would  have 
general  benefits  as  well  as  providing  a  more  accessible  structure  for  engineer 
enhancements .  Note  that  FORCEM  under  both  Options  3  and  4  only  measure  engineer 
capability;  FASTALS  is  projected  to  still  generate  requirements  under  both,  but 
the  ability  of  the  force  to  accomplish  predicted  engineer  workload  will  be 
examined  in  FORCEM  (options  3,  4,  and  5).  In  terms  of  desirability,  ESC  would 
rank  the  viable  options:  4,  3,  and  2.  It  is  thus  ESC's  conclusion  that  to 
adequately  represent  the  contribution  of  engineers  in  FORCEM  the  following  plan 
should  be  adopted:  that  FORCEM  use  division-level  combat  samples  from  the 
planned  engineer  enhanced  version  of  VIC;  that  improvements  be  made  to  FORCEM' s 
representation  of  terrain,  installations,  and  units;  and  that  the  identified 
engineer  tasks  and  effects  be  incorporated  in  FORCEM. 
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I .  INTRODUCTION 

1.  Purpose .  This  annex  presents  the  results  of  a  system  analysis 
performed  by  ESC  to  support  the  development  of  the  Engineer  Functional  Area 
Model  ( EFAM) . 

2.  Scope .  The  analysis  described  in  this  annex: 

a.  Outlines  the  system  to  be  modeled  and  its  environment. 

b.  Defines  the  model's  specifications. 

c.  Presents  an  outline  development  plan  of  desired  program  mile¬ 
stones,  estimated  resource  requirements,  and  coordination  requirements. 

3.  Method .  In  the  field  of  software  engineering,  the  software  life 
cycle  begins  with  the  development  of  the  system's  specifications  and  proceeds 
through  its  design,  implementation,  and  ends  with  the  requirements  to  maintain 
the  model  until  revision,  when  the  cycle  begins  again. ^  The  purpose  of  ESC's 
analysis  was  to  complete  the  first  phase  of  this  cycle:  development  of  the 
system's  specifications.  Figure  D-l  outlines  the  three-step  methodology  ESC 
followed  to  build  a  set  of  functional  requirements  for  EFAM. 

a.  System  outline.  ESC  worked  closely  with  the  United  States  Army 
Engineer  School  (USAES)  to  decide  what  the  model  will  do,  define  how  the  model 
would  be  used,  and  what  information  will  be  output  by  the  model.  After  the 
basic  direction  of  the  model  was  agreed  upon,  ESC  worked  with  the  USAES  to 
evaluate  proposals  of  alternative  model  configurations  --  eventually  deciding 
on  a  design  approach  for  EFAM. 

b.  Requirements  specifications.  Using  the  EFAM  design  approach  as 
a  starting  point,  specifications  were  developed  for  the  model's  battlefield 
representation,  engineer  command  and  control  representation,  engineer  task 
representation,  and  data  inputs. 

(1)  The  requirements  specifications  were  based  on  a  literature 
search  of  regulations,  policy  documents,  studies,  memoranda,  and  similar 
material  pertaining  to  Army  Model  Improvement  Program  (AMIP)  and  force-on- 
force  simulations.  Interviews  were  also  conducted  with  key  personnel  of: 
USAES;  Department  of  the  Army  (DA);  TRADOC  Analysis  Command,  White  Sands 


^Wiener,  Richard,  and  Richard  Sincovec, 
2  and  ADA  (John  Wiley  and  Sons,  1984) 
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(TRAC-WSMR) ;  TRADOC  Analysis  Command,  Fort  Leavenworth  (TRAC-FLVN) ;  and  US 
Army  Corps  of  Engineers  (USACE)  personnel.  Annex  H  presents  a  complete  bibli¬ 
ography  of  sources  cited  or  referenced  while  this  section  was  being  prepared. 

(2)  A  separate  ESC  analysis,  described  in  Annex  F,  set  addi¬ 
tional  criteria  for  EFAM's  engineer  task  representation. 

c.  Development  plan.  A  three -year  development  plan  was  established 
for  the  EFAM  using  time/budget  resource -use  estimates  provided  by  experienced 
model  developers. 

A.  Limits .  The  requirements  specifications  in  section  III  state  what 
EFAM  will  eventually  do,  but  do  not  describe  how  it  will  do  it.  Final  deci¬ 
sions  about  how  EFAM's  supporting  software  will  be  configured  will  be  left  to 
the  software  developer,  who  will  perform  the  detail  design  work  and  eventually 
implement  the  model. 


5.  Background .  The  original  requirements  for  the  development  of 
functional  area  models  (FAMs)  were  established  in  1981  by  Army  Regulation  (AR) 
5-11,  Army  Model  Improvement  Program  (AMIP) .  Additional  emphasis  was  placed 
on  the  program  in  1985  when  General  Thurman,  then  Army  Vice  Chief  of  Staff, 
asked  for  an  assessment  of  AMIP's  FAM  program: 

As  AMIP  continues  to  develop  the  force-on-force  models,  I  want  to 
increase  the  emphasis  on  functional  area  models.  The  FAMs,  if  we 
can  establish  their  credibility,  have  the  potential  payoff  of 
identifying  and  substantiating  the  'eaches'  in  our  procurement 
programs . ^ 

a.  In  response  to  General  Thurman's  tasking,  the  Training  and 

Doctrine  Command  (TRADOC)  schools  and  centers  met  at  Fort  Leavenworth  in 
October  1985  to  define  the  combat  modeling  requirements  for  six  functional 
areas:  maneuver  (infantry,  armor,  aviation,  and  engineer),  fire  support, 

intelligence  and  electronic  warfare  (IEW) ,  combat  service  support  (CSS),  air 
defense,  and  tactical  command  and  control.  The  meeting  established  a  TRADOC 
goal  to  develop,  by  November  1987,  operational  prototypes  for  each  FAM. 
Unfortunately,  1986  saw  little  movement  toward  that  goal. 

b.  In  October  1986,  the  Army  Models  Committee  (AMC)  tasked  the 
AMMO  to  establish  an  advisory  group  to  assess  the  needs,  technical  feasi¬ 
bility,  and  capability  of  the  analytical  community  to  develop  a  set  of  high 
resolution  FAMs.  These  models  would  be  directly  or  indirectly  tied  to  a  corps 
level  combined  arms  combat  model.  Membership  included  representatives  of  Army 
Materiel  Systems  Analysis  Agency  (AMSAA) ,  Concepts  Analysis  Agency  (CAA) , 
TRADOC  Analysis  Command  (TRAC),  and  AMMO.  At  its  first  meeting  on  8-9 
December  1986,  the  group  evaluated,  among  other  issues,  the  relationship 
between  VIC  and  the  combat  modeling  requirements  of  five  functional  areas: 

air  defense,  engineer,  fire  support,  intelligence/electronic  warfare,  and 
combat  service  support.  Several  recommendations  to  the  AMC  Executive  Group 
came  out  of  that  meeting: 

(1)  VIC  appears  to  be  a  reasonable,  balanced,  and  adequate 
representation  of  corps-level  combat. 


^AMIP  briefing  notes,  MAJ  Bruce  Goetz,  Army  Model  Improvement  Program 
Management  Office  (AMMO),  Fort  Leavenworth,  Kansas,  January  1987. 
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(2)  VIC  is  not  detailed  enough  to  meet  the  needs  of  every 
functional  area. 

(3)  VIC  should  be  used  as  the  combat  context  generator  for 
functional  area  analysis. 

(4)  FAM  output  should  be  used  by  the  VIC  design  teams  to 
determine  if  the  reference  version  of  VIC,  which  contains  a  more  abstract 
representation  of  a  function,  provides  the  fidelity  needed  by  the  Army  Study 
Program . 

(5)  Functional  area  models  should  not  be  forcibly  embedded  into 
the  reference  version  of  VIC. 

(6)  The  analytical  community  should  design  and  develop  valid 
FAMs  and  ensure  that  VIC's  representation  of  each  functional  area  is  consis¬ 
tent  with  the  FAMs. 

c.  At  subsequent  meetings  (10-11  March  1987,  13-17  April  1987,  and 
6  October  1987) ,  the  advisory  group  continued  to  review  the  needs  and  capabil¬ 
ities  of  the  functional  areas.  ESC's  participation  at  each  of  these  meetings 
has  been  instrumental  in  obtaining  the  advisory  group's  recognition  of  the 
need  for  an  EFAM  and  AMMO  funding  ($200,000)  for  initial  model  development 
efforts.  The  following  sections  of  this  Annex  present  the  EFAM  program  in 
greater  detail  than  previously  presented  to  the  FAM  advisory  group. 
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II.  OUTLINE  OF  THE  SYSTEM  AND  ITS  ENVIRONMENT 


6 .  Coverage  and  Use . 

a.  Each  proposal  for  improving  the  Army's  equipment,  organization, 
or  training  must  be  analyzed  in  detail  to  demonstrate  the  cost  and  operational 
effectiveness  of  the  proposed  change.  Those  organizations  or  systems  with  the 
greatest  perceived  pay-off  are  chosen.  Combat  engineer  systems  often  do  not 
make  the  initial  cut.  Some  of  the  reasons  are: 

(1)  The  Army  land  combat  models  do  not  adequately  demonstrate 
the  contribution  of  engineer  systems  to  the  combined  arms  battle. 

(2)  Engineer-sponsored  studies  are  typically  not  high  on  the 
TRADOC  list  of  priority  studies.  Therefore,  they  are  often  performed  without 
modeling  support  from  the  TRAC. 

(3)  The  USAES  has  access  to  several  models,  but  none  that  are 
both  adequate  to  address  engineer-specific  questions  and  provide  credible 
results  in  the  eyes  of  the  Army's  analytical  community. 

b.  The  EFAM  will  correct  these  deficiencies  by  providing  engineer 
modelers  with  an  appropriate,  analytically  acceptable  and  approved  corps -level 
(i.e.,  engineer  brigade-level)  model.  In  general,  the  types  of  analyses  which 
this  model  will  be  used  to  address  are: 

(1)  Engineer  force  structure  or  design  questions. 

(2)  Engineer  logistics  questions. 

(3)  Contribution  of  engineers  to  the  combined  arms  conflict. 

c.  In  performing  these  analyses,  the  model  is  likely  to  be  used  as 
both  a  capabilities  and  a  requirements  model. 

(1)  Capabilities  mode.  At  the  outset  of  a  conflict,  a  finite 
set  of  resources  (equipment,  personnel,  or  logistics)  is  available  to  complete 
the  required  work.  In  this  mode,  one  can  analyze  how  much  the  engineer  force 
can  accomplish  and  contribute  with  constrained  resources. 

(2)  Requirements  mode.  In  the  requirements  mode,  resources  are 
not  constrained  or  limited.  The  intent  of  this  type  of  analysis  is  to 
determine  the  combined  arms  demand  for  engineer  work,  and  the  resources 
required  to  meet  that  demand. 
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7.  Information  Outputs.  To  accomplish  the  goals  of  an  EFAM,  the 
following  information  must  be  obtained  from  the  model: 

a.  Task  frequency  information. 

(1)  Chronology  of  engineer  tasks  to  include  time,  task  type, 
location,  emplacing  unit,  manuever  unit  supported,  technique  employed,  and 
task  duration. 

(2)  Number  of  tasks  by  type  over  time. 

b.  Engineer  performance/efficiency  information. 

(1)  Engineer  system  profile  (percentage  of  time  working, 
traveling,  spent  idle,  and  other). 

(2)  Engineer  equipment  and  personnel  attrition  profiles. 

(3)  Number,  type,  and  percentage  of  requested  tasks  which  were 

not  started. 

(4)  Number  and  percentage  of  started  tasks,  by  type,  which  were 
terminated  before  being  finished. 

(5)  Record  of  logistic  item  shortages  and  stockage  levels. 

(6)  Flow  of  repaired  and  reconstituted  engineer  equipment. 

c.  Engineer  contribution/effects  information. 

(1)  Forward  line  of  troops  movement  data. 

(2)  Killer/victim  scoreboard  (including  mines). 

(3)  Battle  duration. 

(4)  Percentage  of  engagements  supported  by  obstacles. 

(5)  Number  of  obstacles  encountered  and  delay  on  each. 

(6)  Average  delay  by  obstacle  type. 

(7)  Percent  of  engagements  supported  by  survivability  tasks 
(protective  positions) . 

(8)  Average  reduction  in  attrition  due  to  survivability  tasks 
(protective  positions). 

(9)  Delay  and  attrition  for  river  crossing  operations. 

(10)  Length  of  downtime  for  damaged  facilities  (airfields, 
major  supply  routes,  ammunition  storage,  hospitals,  etc.). 

(11)  Flow  of  resources  through  logistics  facilities. 

8.  Broad  Alternative  Solutions.  Any  alternative  for  providing  the 
information  required  from  the  EFAM  must  supply  two  items:  a  realistic  corps- 
level  combat  generator  (battlefield  representation  with  combined  arms 
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activities) ,  and  a  detailed  engineer  command  and  control  program  (task  execu¬ 
tion,  unit/force  allocations,  and  equipment/personnel  attrition).  This 
section  will  discuss  several  alternatives  for  developing  an  EFAM. 

a.  Alternative  1- - independent  development.  Both  components  of  the 
EFAM  would  be  developed  independent  of  the  AMIP  models. 

(1)  Advantages.  The  EFAM  could  be  tailored  to  the  specific 
requirements  of  the  engineer  community  and  designed  against  the  ability  of  the 
USAES  to  operate  and  maintain  the  model. 

(2)  Disadvantages.  The  development  of  a  corps- level  combat 
generator  is  not  a  simple  task.  The  development  time  would  be  long  and  the 
resource  requirements  high.  In  addition,  it  would  be  difficult  to  obtain 
credibility  for  the  model  if  it  was  developed  outside  the  AMIP  process. 
Finally,  independent  development  is  contrary  to  the  Army's  goal  to  stem 
proliferation  and  to  standardize  models. 

b.  Alternative  2- -dependent  but  stand-alone.  This  approach  would 
use  an  existing  AMIP  model  as  the  basis  for  the  combat  generator.  Since  VIC 
is  now  the  corps/division  model  of  choice  (Corps/Division  Evaluation  Model 
[CORDIVEM]  has  been  discontinued  and  Conflict  Model  [CONMOD]  is  still  under 
development),  the  combat  generator  would  be  based  on  the  VIC  model.  The 
engineer  command  and  control  programs  within  VIC  would  be  enhanced  to  the 
appropriate  resolution  for  an  EFAM,  VIC's  terrain  representation  and  movement 
algorithms  would  be  improved,  and  this  new  version  of  VIC  (now  called  the 
EFAM)  would  be  a  complete,  stand-alone  model  to  be  used  by  the  USAES. 

(1)  Advantages.  Since  VIC  is  already  a  standard  production 
model,  the  development  time  for  the  EFAM  would  be  reduced.  The  USAES  could 
perform  their  analyses  using  TRADOC  scenarios  and  TRAC  data  bases  already 
developed  for  other  VIC  studies. 

(2)  Disadvantages.  Since  VIC  is  resource  -  intensive ,  an  EFAM 
based  on  VIC  will  be  difficult  for  the  USAES  to  operate  and  maintain.  Since  a 
high- resolution  engineer  representation  in  EFAM  would  probably  produce  results 
that  are  "different"  from  VIC,  it  may  be  difficult  to  establish  credibility 
for  the  model. 

c.  Alternative  3--modular  plug-in.  The  VIC  model  would  contain  a 
balanced  representation  of  the  engineer  functions,  but  at  a  modest  resolution. 
The  EFAM  would  consist  of  a  high-resolution  module  for  engineer  representation 
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that  could  be  plugged  into  VIC  and  replace  its  organic  engineer  representa¬ 
tion. 

(1)  Advantages.  This  is  an  eloquent  approach,  providing  the 
capability  for  the  VIC  model  to  switch  between  low-  or  high- resolution 
engineer  play.  This  EFAM  could  support  the  analysis  needs  of  the  entire 
analytical  community,  not  just  the  USAES .  Finally,  this  approach  would 
produce  a  model  with  the  highest  level  of  credibility,  since  this  is  the 
approach  that  is  the  most  closely  tied  to  VIC. 

(2)  Disadvantages.  The  primary  disadvantage  of  the  plug-in 
approach  is  that  it  may  not  be  possible  to  accurately  play  engineers  without 
modifying  the  current  representation  of  the  battlefield  in  VIC.  The  concept 
should  work  quite  well  for  a  function  like  logistics,  where  items  can  be 
accounted  for,  requested,  supplied,  and  consumed  at  various  levels  of 
resolution.  The  engineers,  on  the  other  hand,  do  not  simply  operate  within 
the  battlefield--  they  modify  it.  Thus,  engineers  are  vital  to  defining  the 
mobility,  countermobility,  and  survivability  of  manuever  forces.  Therefore, 
the  ability  to  represent  engineer  task  and  force  effectiveness  at  a  high  level 
of  resolution  depends  on  some  primary  characteristics  of  the  combat  generator, 
including  terrain  resolution  and  cross-country  movement  algorithms.  Since  the 
current  reference  version  of  VIC  is  not  "plug"  compatible  with  a  high- 
resolution  engineer  module,  the  success  of  the  EFAM  would  rest  on  the  VIC 
community's  willingness  to  incorporate  the  necessary  overhead  into  VIC. 
Finally,  as  in  Alternative  2,  the  resulting  model  will  be  resource- intensive 
and  difficult  for  the  USAES  to  operate  and  maintain. 

9.  General  Design  Approach.  At  this  time,  ESC  recommends  alternative 
2.  Attempting  to  accommodate  both  low-  and  high-resolution  engineer  play  in 
VIC  will  overly  complicate  the  VIC  model.  By  making  the  EFAM  a  special 
purpose,  stand-alone  model,  both  models,  VIC  and  EFAM,  can  be  streamlined  to 
better  serve  their  intended  functions.  On  the  other  hand,  ESC  recognizes  the 
merits  of  Alternative  3  and  will  not  altogether  abandon  this  approach. 

a.  Every  effort  will  be  made  to  maintain  compatibility  between  the 
reference  VIC  model  and  the  EFAM.  The  two  models  will  be  stand-alone,  but 
logically  linked.  Figure  D-2  shows  the  following  general  steps  in  this 
process  (detailed  requirement  specifications  are  discussed  in  Section  III): 


EFAM  DESIGN  APPROACH 


Figure  D-2 

(1)  Step  1.  Replace  the  current  representation  of  engineer 
units  in  VIC  (see  Annex  B)  with  a  more  flexible  modeling  arrangement.  This 
will  improve  the  realism  of  the  engineer  tasks  currently  played  in  the  model 
and  permit  the  inclusion  of  additional  engineer  tasks.  This  modified  version 
of  VIC  is  referred  to  as  the  USACE  R&D  VIC. 

(2)  Step  2.  Systematically  implement  additional  engineer  tasks 
in  the  USACE  R&D  VIC.  Model  modifications  will  be  phased;  starting  first  with 
those  modifications  desired  by  the  engineer  community  for  the  reference 


version  of  VIC,  and  second  with  EFAM  unique  requirements.  Concurrent  with 
this  modeling  effort,  the  following  two  research  programs  will  be  underway: 
the  identification,  collection,  and  validation  of  data  requirements;  and  the 
design,  development,  and  testing  of  improved  unit  movement  and  terrain 
representation.  Both  of  these  efforts  are  needed  to  ensure  that  engineer  task 
effects  are  realistically  modeled. 

b.  Step  2  modifications  will  be  performed  in  phases.  This  itera¬ 
tive  approach  will  periodically  produce  a  new  version  of  the  USACE  R&D  VIC 
which  will  serve  as  a  prototype  EFAM.  Every  effort  will  be  made  to  produce  an 
EFAM  that  satisfies  the  requirements  of  the  engineer  community  without 
radically  departing  from  the  VIC  model. 


III.  REQUIREMENTS  SPECIFICATION 


10 .  Battlefield  Representation . 

a.  Terrain  resolution.  Since  engineers  emplace  and  remove  natural 
or  manmade  obstacles,  the  battlefield  terrain  must  be  specified  with  suffi¬ 
cient  resolution  to  identify  their  location  and  character.  The  terrain  must 
also  be  sufficiently  detailed  to  identify  river  crossing  sites,  cross-country 
mobility,  and  locations  for  protective  positions.  LOC  networks  must  also  be 
specified  so  the  model  can  generate  the  appropriate  number  of  point  obstacles 
(road  craters  and  blown  bridges) .  Finally,  since  urban  areas  are  a  part  of 
the  battlefield,  they  must  be  characterized  in  detail  (see  Annex  E  for  the 
digitized  terrain  requirements  to  support  VIC) . 

b.  Dynamic  movement.  Maneuver  units  of  both  forces  must  be  able  to 
dynamically  alter  their  routes  to  respond  to  the  changes  imposed  by  engineer 
obstacles . 

c.  Threat.  The  threat  forces  must  be  realistically  portrayed  in 
terms  of  capabilities,  vulnerability,  task  times,  and  travel  rates. 

11 •  Engineer  Command  and  Control  Representation. 

a.  Resolution.  Engineer  equipment  must  be  identified  at  the 
individual  item  level,  with  different  types  of  equipment  items  represented. 
Personnel  must  be  identified  to  the  engineer  team  level  (smaller  than  platoon 
size).  The  different  types  of  engineer  teams  (such  as  bridging,  obstacle 
breaching,  or  trail  cutting  teams)  must  be  represented. 

b.  Force  structure.  The  model  must  portray  the  traditional 
engineer  hierarchical  structure  of  teams,  squads,  platoons,  companies,  and 
battalions.  It  must  also  monitor  on-hand  assets  and  modify  or  redistribute 
assets  to  meet  the  mission  needs.  Realistic  command  relationships  must  exist 
(direct  support,  general  support,  etc.)  for  nondivisional  combat  engineer 
units,  as  well  as  for  engineer  heavy  battalions  and  combat  support  equipment 
companies.  Since  many  of  the  studies  supported  by  the  EFAM  will  concern 
future  time  frames,  the  model  must  be  easily  adaptable  to  changing  force 
structures,  unit  designs,  and  materiel. 

c.  Resource  allocation.  The  model  must  manage  all  engineer  items 
of  equipment  and  allocate  personnel  and  equipment  to  tasks.  When  an  engineer 
task  is  requested,  the  required  engineer  assets  travel  from  their  current 
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location  to  the  worksite,  and  perform  the  task.  To  properly  manage  this,  a 
priority  scheme  and  queue  must  be  established  for  engineer  tasks. 

d.  Combat  Service  Support  (CSS).  Engineers  must  be  tied  into  the 
logistics  system.  Class  III,  IV,  and  V  materiel  must  be  managed,  transported, 
and  allocated  to  engineers.  Engineer  equipment  and  personnel  must  also  be 
tied  to  the  support  structure  to  ensure  that  casualties  are  evacuated  and 
replaced,  and  that  damaged  equipment  is  evacuated,  repaired,  and  reissued. 

e.  Attrition.  Engineer  equipment  and  personnel  must  suffer 
attrition  from  both  direct  and  indirect  fires.  The  model  must  assure  that 
this  attrition  is  commensurate  with  the  specific  entity's  vulnerability  and 
can  occur  during  any  phase  of  work  or  movement. 

f.  Engineer  activities  by  non- engineers .  Not  all  engineer  tasks  on 
the  battlefield  are  performed  by  engineer  personnel  and  equipment.  Management 
of  these  activities  and  the  availability  of  resources  to  perform  them  must  be 
handled  within  the  resources  and  priorities  of  other  proponent  branches.  For 
example,  EFAM  should  consider  the  use  of  mines  and  demolition  by  field 
artillery,  aviation,  air  force,  armor,  and  infantry. 

12.  Engineer  Task  Representation.  Annex  F  identifies  those  engineer 
tasks  which  should  be  represented  in  combat  simulations  at  each  level  of  the 
AMIP  hierarchy.  However,  the  Engineer  Model  Improvement  Program  (EMIP)  is 
somewhat  unique,  since  it  is  a  mid- resolution  (corps - level)  simulation  with 
high- resolution  (team-level)  engineer  representation.  The  following  para¬ 
graphs  complement  the  discussion  of  engineer  tasks  in  Annex  F,  and  identify 
the  engineer  tasks  to  be  modeled  in  the  EFAM. 

a.  Mobility  tasks.  Figure  D-3  lists  the  four  major  categories  of 
mobility  tasks  that  must  be  represented  in  the  EFAM. 

(1)  Engineers  must  have  alternative  courses  of  action  for 
overcoming  each  type  of  obstacle  encountered.  These  alternatives  should 
encompass  breaching  techniques  --  with  or  without  engineer  support  --  plus  a 
by-pass  option. 

(2)  The  orchestration  or  action  of  the  maneuver  units  during 
counterobstacle  operations  must  be  consistent  with  the  breaching  technique 
being  employed. 

(3)  Each  type  of  obstacle  must  have  individual  characteristics 
(width,  depth,  effects  on  maneuver  elements). 
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Figure  D-3 

(4)  The  maneuver  forces  cannot  have  perfect  knowledge  of  the 
obstacle  boundaries  or  locations.  Knowledge  of  an  obstacle  is  only  obtainable 
through  intelligence  or  encounter. 

(5)  The  model  must  play  the  following  obstacle  breaching 

techniques : 

(a)  Forcing  through:  Forcing  through  is  the  crossing  of 
an  obstacle  without  the  benefit  of  countermine  or  counterobstacle  equipment. 
Visual  observation  is  the  only  means  dismounted  troops  or  vehicle  drivers  use 
to  avoid  obstacles  or  mines.  Negotiating  the  obstacle  in  this  manner  involves 
the  highest  risk  and  is  attempted  only  when  it  is  imperative  to  maintain  the 
momentum  of  the  attack  or  when  no  other  means  is  available. 

(b)  Hasty  breach:  In  the  hasty  breach,  the  attacking 
force  maintains  the  momentum  of  the  attack  by  attempting  to  breach  "in  stride" 
as  it  encounters  the  minefield  or  obstacle.  A  hasty  breach  is  conducted  by 
maneuver  units  with  immediately  available  assets  and  often  without  combat 
engineer  participation. 
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(c)  Deliberate  breach:  The  deliberate  breach  is  conducted 
when  it  is  not  possible  to  take  the  minefield  or  obstacle  in  stride  or  after  a 
hasty  breach  has  failed.  Combat  engineer  support  is  essential.  A  deliberate 
breach  will  normally  be  conducted  after  momentum  has  been  lost.  More  time  is 
required  for  reconnaissance,  planning,  and  build-up  of  necessary  resources 
than  is  possible  for  a  hasty  breach. 

(6)  Engineers  must  be  able  to  create  and  maintain  combat  roads 
and  trails  as  the  simulation  progresses.  The  construction  time  for  these 
tasks  will  depend  on  the  equipment  available  and  the  terrain  conditions  being 
encountered.  The  mobility  rates  along  these  roads  will  be  commensurate  with 
the  quality  of  road  constructed. 

b.  Countermobility  tasks.  Figure  D-4  lists  the  countermobility 
tasks  that  must  be  represented  in  the  EFAM. 

EFAM  COUNTERMOBILITY  TASKS 


Install  linear  obstacles 
Conventional  minefields 
Scatterable  minefields 
Antitank  ditches 
Other  linear  obstacles 
Antitank  wall 
Concertina  and  barbed  wire 
Flooding 
Fire 

Complex  obstacles 

Install  point  obstacles 
Road  craters 
Bridge  demolition 


Figure  D-4 

(1)  All  types  of  minefields  must  be  represented  with  variable 
size  and  density.  The  emplacement  time,  size,  and  density  must  be  consistent 
with  the  delivery  device.  Types  of  scatterable  mines  should  include  the 
ground  emplaced  mine  scattering  system  (GEMSS),  VOLCANO,  modular  pack  mine 


D- 


system  (MOPMS) ,  area  denial  artillery  munition  (ADAM)/remote  anti-armor  mine 
system  (RAAMS) ,  wide  angle  mine  (WAM) ,  and  GATOR/M56. 

(2)  Each  individual  mine  type  must  have  realistic  probabilities 
of  kill,  reliabilities,  and  self-destruct  times. 

(3)  Obstacles,  like  minefields,  must  be  variable  in  size.  The 
emplacement  time  and  obstacle  size  must  be  consistent  with  the  emplacement 
device.  Various  techniques  can  be  used  for  a  single  type  of  obstacle.  A  tank 
ditch  is  a  prime  example,  and  any  of  these  techniques  can  create  it:  armored 
combat  earthmover  (ACE),  dozer,  scooploader,  or  explosives. 

(4)  Each  type  of  obstacle  must  have  the  option  of  being 
featured  with,  or  surrounded  by,  a  minefield. 

c.  Survivability  tasks.  Figure  D-5  lists  the  survivability  tasks 
that  must  be  represented  in  the  EFAM. 


EFAM  SURVIVABILITY  TASKS 


Prepare  fighting  positions  for  direct  fire  systems 
Prepare  positions  for  indirect  fire  and  other  systems 
Camouflage  and  deception 


Figure  D-5 


(1)  Engineers  must  be  able  to  construct  fighting  positions  for 
tactical  vehicles  and  weapons  systems.  Protective  emplacements  for  artillery, 
air  defense  units,  and  logistics  concentrations  must  be  an  option,  as  well  as 
the  hardening  of  key  command  and  control  facilities. 

(2)  When  maneuver  units  halt,  engineers  must  build  and  improve 
as  many  protective  positions  as  possible.  When  units  stop  for  breaching 
operations,  for  example,  engineers  should  provide  protective  positions  for 
antitank  and  indirect  fire  weapons  and  for  critical  supplies  such  as  ammuni¬ 
tion  . 
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(3)  Fighting  positions  must  be  represented  by  three  levels: 
half  defilade,  firing  defilade,  and  full  defilade.  Each  level  should  reduce 
the  exposed  target  area  with  a  resulting  reduction  in  probability  of  kill. 

(4)  Through  the  employment  of  engineers,  or  other  camouflage 
efforts ,  the  level  of  acquisition  should  be  reduced  for  vehicles  or  personnel 
who  have  employed  camouflage. 

d.  Sustainment  engineering  tasks.  Figure  D-6  lists  the  sustainment 
engineering  tasks  that  must  be  represented  in  the  EFAM. 

EFAM  SUSTAINMENT  ENGINEERING  TASKS 

Improve  river  crossing  sites  for  follow-on  forces 
Fixed  bridging 
Float  bridging 

Improve  assault  breaches  for  follow-on  forces 

Clear  minefields 
Widen  lanes 

Prepare  and  maintain  forward  airlanding  facilities 

Maintain  main  supply  routes  (MSR) 

Roads 

Railroads 

Bridges 

Prepare  and  maintain  sites  for  CS  and  CSS  units 

Rehabilitate  and  maintain  rear  area  facilities 

Repair  Airfield  Damage 

Construct  and  repair  port  and  waterfront  facilities 

Figure  D-6 

(1)  Each  facility  (roads,  railroads,  petroleum,  oils,  lubri¬ 
cants  [POL]  sites,  hospitals,  etc.)  must  be  deteriorated  with  usage,  which 
reduces  the  flow  of  assets  through  that  facility.  Engineers  can  expend 
maintenance  effort  to  keep  these  facilities  operating  at  full  capacity. 
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(2)  All  facilities  must  be  capable  of  receiving  war  damage, 
which  also  precludes  or  limits  their  use.  Engineers  can  then  be  used  to 
repair  these  facilities.  -» 

i 

13.  Data  Inputs .  EFAM's  high  resolution  play  of  engineer  force 
capabilities  and  engineer  task  effectiveness  will  require  an  intensive  data 
development  effort.  Since  the  architectural  design  is  based  on  the  VIC  model, 
the  logic  and  structure  of  the  data  base  has  been  predefined,  but  much  of  the  -* 

engineer ing- related  data  within  VIC  will  have  to  be  replaced  or  supplemented. 

Figure  D-7  lists  the  five  major  categories  of  data  that  are  vital  for  EFAM 
operation . 

EFAM  DATA  REQUIREMENTS 


« 


I 

0 


« 


« 


1.  Engineer  task  representation 

Task  priority 
Techniques  available 
Resource  requirements 
Base  preparation  time 
Engineer  team  movement  rates 
Task  completion  times 

2.  Weapon  systems  vulnerability 

Exposed 

Firing  defilade 
Half  defilade 
Full  defilade 

3.  Engineer  systems  vulnerability 

4.  Minefield  systems  effectiveness  (by  density  and  type) 

Attrition  factors 
Self-destruct  times 

5.  Battlefield  representation 

Terrain 

Cross-country  mobility 

Lines  of  Communication  (LOC)  capacities  and  degrada¬ 
tion  factors 
Depots 
Roads 
Railroads 
Airfields 
Ports 
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Figure  D-7 
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IV.  DEVELOPMENT  PLAN 


14.  Program  Milestones  and  Work  Schedule.  Using  VIC  as  the  base  model 
for  the  EFAM  will  fix  both  the  logical  and  physical  design  of  the  model,  as 
well  as  structure  of  the  data  base.  The  developmental  program,  therefore, 
should  be  viewed  as  a  model  enhancement  program  with  an  abbreviated  life 
cycle.  Most  of  the  software  developer's  effort  will  be  spent  on  modifying  VIC 
to  accommodate  the  specifications  cited  in  section  III.  Those  modifications 
that  are  also  recommended  for  future  reference  versions  of  the  VIC  model  (see 
Annex  B)  are  scheduled  first.  All  modifications  should  take  no  longer  than  3 
yea  s,  and  the  operational  model  should  be  delivered  to  USAES  in  FY91. 
Prototypes  will  be  available  on  a  one -year  cycle.  Figure  D-8  shows  the 
program  milestones  and  work  schedule. 
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15.  Resource  Requirements.  The  majority  of  the  EFAM  program  schedule 
can  be  accomplished  through  a  cooperative  effort  by  Construction  Engineering 
Research  Laboratory  (CERL)  and  Waterways  Experiment  Station  (WES).  There  are 
two  possible  exceptions:  digitized  terrain  requirements  should  be  met  by 
Engineer  Topographic  Laboratories  (ETL) ,  and  data  requirements  by  a  contrac¬ 
tor.  ESC  estimates  that  the  total  EFAM  development  effort  will  require  16 
professional  staff  years,  and  cost  slightly  less  than  $2  million  ($120,000  per 
professional  staff  year).  Since  the  VIC  program  directly  benefits  from 
approximately  75  percent  of  this  effort  (as  shown  in  Figure  D-8) ,  the  net  cost 
of  the  EFAM  will  be  considerably  less.  The  phasing  of  the  professional  staff 
year  estimates  is  shown  in  Figure  D-9. 


EFAM  RESOURCE  REQUIREMENTS 
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16.  Coordination  Requirements.  As  the  EFAM  program  monitor,  ESC  will 
establish  and  maintain  the  necessary  coordination  and  support  agreements.  The 
primary  mechanism  for  this  coordination  will  be  an  EFAM  Advisory  Group. 
Membership  will  be  solicited  from  the  following  key  organizations: 

a.  USAES:  model  proponent  and  user  representative 

b.  AMMO/FAM  advisory  group:  funding  support 

c.  TRAC:  proponent  of  VIC 

d.  Directorate  of  Research  and  Development,  USACE:  program 
development  for  USACE  laboratories 

e.  ETL:  digitized  terrain  requirements 

f.  AMSAA:  proponent  for  item  systems  data 

g.  OACE:  technical  monitor 
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I .  INTRODUCTION 


1.  Purpose .  This  annex  identifies  requirements  for  digital  terrain 
data  (DTD)  in  combat  simulations  at  each  level  in  the  hierarchy  of  Army 
models.  Three  specific  models  (CASTFOREM,  VIC,  and  FORCEM)  were  examined  to 
determine  how  they  use  terrain  data  and  to  assess  the  availability  of  DTD  at 
the  different  levels  of  resolution  required  by  these  models. 

2.  Scope .  This  analysis  evaluates: 

a.  The  status  of  DTD  production  in  the  Army  and  at  the  Defense 
Mapping  Agency  (DMA)  --  in  terms  of  database  content  and  geographic  coverage. 

b.  The  DTD  requirements  of  high-,  medium-,  and  low- resolution  Army 
models  (as  represented  by  CASTFOREM,  VIC,  and  FORCEM)  --  also  in  terms  of 
database  content  and  geographic  coverage. 

3.  Background .  Advances  in  data  collection  and  processing  technology 
are  changing  the  way  the  mapping,  charting,  and  geodetic  (MC&G)  community 
collects  and  represents  terrain  information.  Labor-intensive  manual  mapping 
procedures  are  giving  way  to  a  variety  of  automated  and  semi-automated  mapping 
methods  that  electronically  digitize  topographic  features  and  terrain  informa¬ 
tion.  These  automated  capabilities  will  greatly  enhance  the  ability  to  store, 
manipulate,  update,  and  display  topographic  products.  The  transformation  is 
occurring  at  all  levels  of  the  Department  of  Defense,  from  the  mapping  experts 
at  DMA  to  Army  topographic  field  units.  As  a  result,  MC&G  organizations, 
methods,  and  equipment  are  now  being  prepared  to  operate  in  the  digital 
environment  of  the  future.  These  changes  will  affect  the  way  combat  simula¬ 
tion  models  accept  and  interpret  information  about  the  physical  battlefield 
environment . 

a.  DMA  responsibilities.  DMA  produces,  revises,  and  distributes 
standard  MC&G  products  throughout  the  DOD  community.  To  keep  pace  with  the 
demand  for  digital  products,  DMA  is  changing  its  mapping  methods  and  equip¬ 
ment.  DMA's  Systems  Center  is  coordinating  the  design  and  development  of  the 
Mark  90  modernization  program,  which  is  a  new,  computer-oriented,  highly  auto¬ 
mated  production  system.  The  Mark  90  system  is  designed  to  produce  28  or  more 
standard  products. ^  A  new  tactical  terrain  data  (TTD)  set  that  is  currently 

^ Tactical  Terrain  Data  Prototype  (DMA,  9  October  1987). 
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under  development  will  be  added  to  the  list  of  Mark  90  products  in  the  near 
future.  The  complete  set  of  Mark  90  standard  products  will  meet  a  significant 
portion  of  the  DOD  community's  digital  terrain  requirements.  However,  DMA 
will  not  begin  TTD  production  until  the  Mark  90  system  reaches  its  initial 
operational  capability  in  1992  or  later.  In  the  interim  (1988-1992),  the 
Army's  requirements  for  DTD  must  be  met  with  current  standard  products  or 
interim  terrain  data  (ITD)  produced  to  meet  the  most  urgent  needs.  Among  the 
standard  digital  terrain  products  DMA  can  now  produce  are: 

(1)  Digital  terrain  elevation  data  (DTED) 

(2)  Digital  feature  analysis  data  (DFAD) 

(3)  Counter-Artillery ,  Counter-Battery  Locating  System 

(FIREFINDER) 

(4)  Vertical  Obstruction  Data  (VOD) 

(5)  Terrain  Contour  Matching  (TERCOM) 

b.  Army  responsibilities.  The  Army  is  also  changing  to  take 
advantage  of  the  capabilities  of  the  new  digital  topographic  world.  The 
Engineer  Topographic  Laboratories  (ETL)  are  developing  the  digital  topographic 
support  system  (DTSS)  that  will  enable  US  Army  topographic  field  units  to 
operate  in  a  digital  production  mode.  Two  reports  prepared  by  the  ETL  outline 
Army  digital  terrain  requirements  for  weapon  systems,  tactical  support 
systems,  training  systems,  and  modeling.2  Initially,  DMA  indicated  that 
requirements  not  met  by  the  current  standard  digital  products  (DTED,  DFAD) 
would  not  be  satisfied  until  the  Mark  90  system  became  operational  and  started 
producing  TTD.  Thus,  the  Army  is  faced  with  a  near-term  (1988-1992)  shortfall 
in  the  availability  of  new  digital  terrain  data.  The  Army  topographic 
community  is  concerned  that  TTD  production  by  Mark  90  in  1992  may  be  optimis¬ 
tic  --  and  when  the  Mark  90  system  comes  on  line,  it  will  take  time  to  develop 
the  data  bases  and  build  the  area  coverage  needed  to  satisfy  all  mid-term 
(1993-2002)  Army  DTD  requirements.3  However,  ETL' s  Concepts  and  Analysis 

O 

Herrmann ,  Richard  A.,  et  al . ,  Army  Digital  Topographic  Data  Require¬ 
ments,  Report  ETL-GSL-4  (ETL,  August  84)  and  Regis  J.  Orsinger,  et  al . ,  Army 
Tactical  Digital  Terrain  Data  Requirements,  Report  ETL-SR-1  (ETL,  July  1987). 

3Personal  conversation  between  Mr.  Richard  L.  Taylor  of  ESC,  and  LTC  John 
Olesak,  Office  of  the  Deputy  Chief  of  Staff  for  Intelligence  (ODCSINT) , 
November  20,  1987  and  the  ETL  Command  Briefing  presented  to  ESC  personnel  by 
COL  Alan  Laubscher,  November  30,  1987. 


Division  (CAD)  is  committed  to  ensuring  that  the  Army's  near-term  requirements 
for  a  tactical- level  digital  terrain  analysis  product  are  fulfilled  by  an 
acceptable  means.  To  this  end,  both  ETL  and  the  Office  of  the  Deputy  Chief  of 
Staff  for  Intelligence  (ODCSINT)  have  represented  the  Army  in  discussions  with 
the  Defense  Mapping  Agency  (DMA)  to  provide  an  ITD  product  to  adequately  and 
expediently  service  the  Army's  near-term  (1988-1993+)  tactical  and  analysis 
community  requirements  for  digital  terrain  data  sets  (before  TTD  is  available 
in  volume).  DMA's  recent  decision  to  support  the  DTSS  with  a  volume  of  ITD 
required  for  operational  deployment  has  been  underscored  by  their  commitment 
to  develop  a  product  specification  for  ITD  by  31  August  1988  and  deliver  a 
prototype  data  set  to  the  Army  by  the  end  of  1988.  ITD,  to  be  acceptable  by 
the  Army  must  be  easily  usable,  cost  effective,  and  adaptable  to  either 
existing  or  near-term  fieldable  Army  tactical  and  non-tactical 
systems/programs  with  respect  to  their  operating  systems  and  specific 
applications.  ITD  must  also  be  co -producible  by  the  Army  and  private 
industry.  Finally,  ITD  should  be  economically  translatable  to  the  future  DMA 
TTD. 

4.  Limits .  This  analysis  focuses  on  the  MC&G  community's  ability  to 
meet  the  DTD  needs  of  existing  models  --  it  does  not  attempt  to  specify 
standard  DTD  formats,  structures,  or  transformations.  DTD  standards  should  be 
determined  by  a  thorough  analysis  and  evaluation  of  the  digital  terrain 
requirements  of  weapon  systems  and  tactical  support  systems.  Models  should 
take  advantage  of  the  available  DTD  products,  but  they  should  not  preempt  the 
requirements  of  systems  in  the  field.  This  analysis  did  consider  the  results 
of  a  1984  ETL  study  which  consolidated  the  Army's  DTD  requirements  (to  include 
the  Army  modeling  community).^  These  specifications  form  the  basis  of  DMA's 
TTD  specifications,  as  well  as  the  Army's  special  terrain  data  (STD) 
specifications.  The  STD  specifications  are  designed  to  meet  Army  high- 
resolution  DTD  requirements  not  met  by  TTD.  Together,  TTD  and  STD  will  serve 
as  the  Army's  standard  DTD  sets  for  the  future. 

5.  Approach .  This  analysis  began  with  a  review  of  Department  of  the 
Army  (DA)  Pamphlet  25-30  to  identify  technical  manuals,  field  manuals, 

^ At  my  Digital  Topographic  Data  Requirements ,  Volume  IV:  US  Army  Specifi¬ 
cations  for  DTD  Requirements,  Report  ETL-GSL-4  (ETL,  August  1984). 


regulations  or  other  publications  relating  to  the  Army's  use  of  DTD.  Next, 
interviews  were  conducted  with  the  key  personnel  who  produce  and  use  DTD,  as 
well  as  those  who  prepare  reports  relating  to  DTD.  Among  those  interviewed 
were  representatives  of  various  DOD  and  Army  staff  elements,  including:  DMA, 
ODCSINT,  and  the  Assistant  Chief  of  Engineers  (ACE).  Information  pertinent  to 
the  state  of  DTD  production  was  also  obtained  from  ETL,  the  Waterways  Experi¬ 
ment  Station  (WES) ,  the  US  Army  TRADOC  Analysis  Command  at  White  Sands  Missile 
Range  (TRAC-WSMR) ,  and  the  US  Army  Concepts  Analysis  Agency  (CAA) . 


II.  STATUS  OF  DTD  DATA  AND  PRODUCTION 


6.  DTD  Production.  The  uses  of  DTD,  the  technology  needed  to  generate 
DTD,  and  the  organizations  tasked  to  produce  DTD  have  all  evolved  rapidly  over 
the  past  10  years.  The  production  of  standard  military  DTD  is  the  mission  of 
DMA.  ETL  has  the  responsibility  of  coordinating  Army  requirements  with  DMA. 
ETL  also  has  responsibility  for  managing  research,  development,  and  production 
of  Army  DTD  requirements  that  are  not  met  by  DMA.  The  US  Army  Corps  of 
Engineers  Research  and  Development  (USACE  R&D)  community,  Army  field  units, 
and  private  contractors  are  also  involved  in  producing  DTD  to  meet  special 
requirements.  Because  the  different  DTD  products  developed  by  these 
organizations  have  evolved  over  time  to  meet  specific  requirements,  they  are 
not  always  compatible.  The  different  DTD  vary  in  content  (elevation,  vegeta¬ 
tion,  lines  of  communication,  etc.),  format  (raster  or  vector),  resolution 
(raster  grid  size  or  vector  data  density) ,  data  structure  (data  base  layout) , 
accuracy  (location  error),  geographic  coverage  (Europe,  Central  America, 
etc.),  and  means  of  data  base  generation  (fully  automated  or  manually 
entered) .  Figure  E-l  gives  a  summary  of  the  features  of  some  key  DTD  data 
sets.  The  long  range  goal  of  the  MC&G  community  is  to  standardize  DTD 
requirements.  However,  until  the  DMA  Mark  90  program  becomes  operational,  the 
modeling  community  must  make  the  best  use  of  all  existing  sources  of  DTD. 
Therefore,  this  analysis  does  not  distinguish  between  original  sources  of 
digital  terrain  production  and  sources  that  acquire  digitized  elevation  data 
from  another  DTD  source  and  add  additional  terrain  feature  data.  It  was 
assumed  that  DTD,  no  matter  where  or  how  produced,  is  available  to  support 
model  users. 

7.  DMA .  Two  offices  at  DMA  are  primarily  responsible  for  producing 

DTD:  the  Hydrographic/Topographic  Center  and  the  Aerospace  Center.  Two 

significant  standard  DTD  products  prepared  in  these  centers  are  considered 
essential  to  Army  modelers:  digital  terrain  elevation  data  (DTED) ,  and 
digital  feature  analysis  data  (DFAD) .  DTD  for  the  FIREFINDER  system  is  also 
produced  at  DMA  and,  where  coverage  is  available,  it  should  be  considered  for 
model  use.  Since  the  location  of  DTD  coverage  for  FIREFINDER  could  reveal 
potential  deployment  locations  of  FIREFINDER  systems,  this  information  is 
classified  and  is  not  included  in  this  report.  DMA  has  also  produced  limited 
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A  SUMMARY 

OF  MAJOR  DTD  DATA 

SET  FEATURES 

DATA 

SET 

STATUS 

FEATURE 

DENSITY 

TERRAIN  FEATURES 

DTED 

(level  1) 

operational 

3  arc -sec 
(100  m) 

elevation 

DTED 

(level  2) 

limited 

coverage 

1  arc -sec 
(30  m) 

elevation 

DFAD 

(level  1, 
edition  1) 

operational 

1:250,000 
map  equivalent 

vegetation,  surface  material 

DFAD 

(level  1, 
edition  2) 

limited 

coverage 

1:250,000 
map  equivalent 

vegetation,  surface  material, 
LOCs 

DFAD 

(level  1-C) 

limited 

coverage 

(cartographic 

sources) 

1:250,000 
map  equivalent 

vegetation,  surface  material, 
LOCs 

DFAD 

(level  2, 
edition  1) 

limited 

coverage 

1:50,000 
map  equivalent 

vegetation,  surface  material 

DFAD 

(level  2, 
edition  2) 

limited 

coverage 

1:50,000 
map  equivalent 

vegetation,  surface  material, 
LOCs 

ART BASS 

operational 
(non- s  tandard 
product) 

12.5-25  m 

elevation,  vegetation,  CCM, 
rivers,  roads,  railroads,  and 
bridges 

Mobility 

Database 

(WES) 

operational 
(non-standard 
product ) 

25-100  m 

elevation,  tree  height,  CCM, 
roads,  vehicle  speeds 

ALBE 

limited 
coverage 
(tech  base 
demonstration) 

100m 

elevation,  vegetation,  slope, 
surface  material,  obstacle 
height,  canopy  closure,  roads 
rivers,  railroads,  bridges, 
tunnels,  dams,  airfields  and 
meteorology 

TTD 

developmental 

1:50,000 
map  equivalent 

elevation,  vegetation,  slope, 
surface  material,  obstacles, 
urban  areas,  rivers,  roads, 
railroads,  bridges,  and 
tunnels 

Figure  E-l 
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secs  of  non-standard  DTD.  The  initial  sets  of  DTD  for  the  Army  Training 
Battle  Simulation  System  (ARTBASS)  were  produced  by  DMA  (ETL  is  now 
coordinating  the  production  of  additional  DTD  for  ARTBASS  through  contract) . 
DMA  also  produced  the  non-standard  DTD  set  called  ITD.  In  one  form  or 
another,  these  products  supply  most  of  the  DMA-produced  DTD  used  by  Army 
combat  simulation  models.  See  Appendix  E-l  for  displays  of  the  geographic 
coverage  of  these  products.  DMA  also  produces  two  hard  copy  terrain  data  sets 
that  are  primary  sources  of  terrain  feature  data  for  encoding  in  DTD  products 
--  tactical  terrain  analysis  data  base  (TTADB)  is  a  set  of  feature  overlays  at 
1:50,000  scale,  and  planning  terrain  analysis  data  base  (PTADB)  is  a  set  of 
overlays  at  1:250,000  scale. 

8.  USACE  R&D  Centers.  Three  USACE  R&D  laboratories  are  producing  or 
updating  DTD  for  Army  use.  ETL  has  the  lead  for  DTD,  but  WES  and  the 
Construction  Engineering  Research  Laboratory  (CERL)  both  produce  DTD  products 
under  reimbursable  agreements  to  meet  certain  Army  requirements. 

a.  ETL.  Four  non-standard  DTD  sources  designed  to  meet  unique  Army 
requirements  are  managed  by  ETL:  two  are  the  responsibility  of  the  Geographic 
Sciences  Laboratory  (GSL)  and  two  are  the  responsibility  of  the  Terrain 
Analysis  Center  (TAC) . 

(1)  GSL  oversees  the  terrain  analysis  work  station  (TAWS) 
project,  the  DTSS ,  and  the  air  land  battle  environment  (ALBE)  test  beds. 

These  GSL  systems  are  based  on  the  Analytical  Mapping  System  (AMS) /Multiple 
Overlay  and  Statistical  System  (MOSS)  geographic  information  system  (GIS) .  A 
GIS  is  a  system  for  encoding,  processing,  manipulating,  and  generating  spatial 
data  --  in  this  case,  terrain  information.  Each  system  can  produce  DTD  but 
only  does  so  for  its  own  use.  Both  systems  have  been  using  hard  copy  TTADBs 
as  source  materials. 

(2)  TAC  is  now  installing  a  GIS  with  the  intent  of  processing 
worldwide  water  resources  data  in  digital  format.  This  will  give  TAC ' s  GIS 
the  ability  to  expand  to  include  multi-theme  DTD.  TAC  is  also  the  Army's 
center  for  transforming  DMA-produced  DTED  from  tape  to  computer  disk  and  video 
cassette  for  use  on  Microfix(T)  systems.  TAC  produces  hard  copy  ARTBASS  data 
for  Army  users  and  manages  contracts  for  the  production  of  DTD  for  ARTBASS. 

b.  WES.  The  Mobility  Systems  Division  of  WES's  Geotechnical 
Laboratory  began  developing  digital  mobility-terrain  data  bases  in  1970  to 
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support  the  evaluation  and  validation  of  the  Army  Mobility  Model  (AMM) . 
Continued  development  of  mobility- terrain  data  bases,  funded  mainly  by 
Training  and  Doctrine  Command  (TRADOC) ,  has  focused  on  providing  realistic 
mobility  input  to  the  CARMONETTE  and  CASTFOREM  wargaming  models.  The  Modeling 
and  Terrain  Unit  of  the  Mobility  Systems  Division  produces  DTD  using  a 
commercially  developed  GIS  called  ARC/INFO.  ARC/INFO  is  a  GIS  system  that  can 
process  and  generate  DTD  from  imagery,  map  sheets,  and  terrain  overlays.  WES 
uses  many  different  terrain  source  materials,  including  TTADB . 

c.  CERL.  Although  CERL  has  not  produced  any  DTD  in  support  of  Army 
ccmbat  simulation  requirements,  its  Geographical  Resources  Analysis  Support 
System  (GRASS)  can  produce  and  process  DTD  data.  This  system  is  a  GIS  which 
supports  CONUS  installation  planning  and  maintenance  done  by  the  USACE 
Engineering  and  Housing  Support  Center  (EHSC) .  GRASS  DTD  has  been  produced 
for  Fort  Hood,  and  Fort  Carson,  and  is  now  being  generated  for  the  Hoenfels 
Training  area  in  West  Germany. 

d.  Summary.  Generically,  the  Army  DTD  is  characterized  by  ARTBASS , 
TAWS,  ALBE,  and  the  WES  data  bases.  While  there  are  significant  differences 
in  these  data  sets  in  terms  of  their  state  of  development  and  coverage,  they 
each  define  terrain  f  atures  as  well  as  basic  terrain  elevation  data.  These 
feature  data  sets  add  information  on  vegetation,  surface  materials,  surface 
drainage,  transportation,  and  obstacles  to  more  fully  describe  the  terrain 
than  can  be  done  with  elevation  data  alone.  (Appendix  E-3  lists  the  documents 
which  give  the  specifications  for  these  data  sets.)  These  systems  can  accept 
digital  terrain  elevation  data  from  other  sources  such  as  DTED  or  they  can 
generate  their  own  digital  terrain  elevation  data  through  manual  means. 
Additional  terrain  feature  information  for  these  DTD  sets  is  manually  input 
from  hard  copy  sources  such  as  the  TTADB,  standard  1:50,000  scale  topographic 
line  maps,  and  other  collateral  sources. 

9.  Army  Engineer  Field  Units.  Engineer  Topographic  units  are'  develop¬ 
ing  the  capability  to  produce  and  maintain  DTD: 

a.  29th  Engineer  Battalion  (Topographic).  The  29th  is  the  Pacific 
theater  topographic  support  battalion.  The  battalion  is  now  installing  the 
first  phase  of  its  digital  modernization  plan  --  a  Microvax  II  system  which 
will  serve  as  the  foundation  for  DTD  production  and  processing.  Later  phases 
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will  install  various  elements  of  the  ALBE  test  bed  system.  By  the  end  of 
1988,  the  29th  will  begin  converting  hard  copy  TTADBs  to  digital  form. 

b.  649th  Engineer  Battalion  (Topographic).  The  649th  is  the 
European  theater  topographic  support  oattalion.  The  battalion's  limited  DTD 
processing  is  now  done  by  terrain  teams  using  Microfix  (T)  systems.  The  649th 
plans  to  eventually  expand  its  DTD  production  capability  to  better  support  US 
Army  Europe  (USAREUR)  terrain  product  needs . 

c.  Other  Topographic  Units.  Similar  conditions  exist  at  the  30th 
Engineer  Battalion  (Topographic),  which  supports  Third  US  Army  missions,  and 
the  1203d  Engineer  Battalion  (Topographic),  which  is  a  National  Guard  unit. 

d.  The  growing  capability  of  field  units  to  produce  DTD  must  be 
coordinated  by  ETL  to  make  sure  the  data  sets  produced  are  formatted  properly 
and  are  available  to  users  throughout  the  Army  and,  thus,  avoid  needless 
duplication  of  effort. 

10.  Contractors .  Private  firms  have  been  a  source  of  DTD  in  the  past, 
and  are  expected  to  meet  a  portion  of  the  Army's  outstanding  DTD  requirements 
in  the  future.  The  BDM  Corporation,  the  Jet  Propulsion  Laboratory  (JPL) ,  and 
various  architectural  and  engineering  firms  have  been  suppliers  of  DTD  in  the 
past.  Their  DTD  products  are  typically  designed  to  support  a  specific  model, 
analysis,  or  GIS  data  base.  Once  developed,  the  data  can  be  applied  to  other 
uses  as  well.  Since  contractor-produced  DTD  is  typically  in  non-standard 
format,  other  uses  normally  require  reformatting. 
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III.  DTD  REQUIREMENTS  FOR  ARMY  MODELS 


11.  DTD  for  The  Hierarchy  of  Army  Models.  Every  model  has  different 
requirements  for  terrain  data  based  on  its  internal  design,  the  types  and 
sizes  of  forces  it  represents,  the  kinds  of  studies  that  use  it,  and  the 
different  geographic  locations  it  must  portray.  The  Army  Model  Improvement 
Program  (AMIP)  classifies  models  into  a  hierarchy  based  on  their  level  of 
resolution.  High  resolution  models  require  the  greatest  terrain  detail  but 
because  they  play  smaller  units  (battalion  and  below) ,  they  operate  on  limited 
blocks  of  terrain.  Medium  resolution  models  need  blocks  of  terrain  large 
enough  to  maneuver  division-  and  corps -size  units  and  they  sacrifice  some 
terrain  detail  to  get  the  area  coverage  they  need.  Low  resolution  models 
cover  an  entire  theater  of  operation  and,  therefore,  must  be  able  to  represent 
the  geographic  characteristics  of  theater  lines  of  communication  and 
strategically  important  terrain  features  like  major  avenues  of  approach. 
However,  at  the  theater  level  it  is  not  necessary  to  explicitly  represent 
terrain  in  enough  detail  to  support  the  play  of  tactical  operations.  ESC 
looked  at  the  three  AMIP  automated  simulations  for  the  three  levels  in  the 
hierarchy  of  Army  models  to  better  define  the  terrain  requirements  at  each 
level  of  resolution.  The  three  models  (CASTFOREM,  VIC,  AND  FORCEM)  are 
discussed  in  detail  in  Annexes  A,  B,  and  C.  Figure  E-2  gives  a  summary  of  the 
terrain  requirements  of  each  model,  and  their  use  of  DTD  is  summarized  in  the 
following  paragraphs. 

12.  CASTFOREM  Model  Description.  This  evaluation  of  CASTFOREM 's  DTD 
requirements  is  based  on  a  review  of  CASTFOREM  documentation  and  interviews 
with  the  persons  who  maintain  the  CASTFOREM  model.  CASTFOREM  has  a  modular 
structure.  Events  in  the  model  trigger  action  in  eight  process  modules: 
command  and  control,  communications,  engineer,  movement,  engagement, 
surveillance,  system/environment,  and  combat  service  support  (CSS).  These 

^CASTFOREM  Executive  Summary  (TRAC-WSMR,  Simulation  Support  Division  III, 
20  September  1986);  CASTFOREM  Scenario  Writer's  Guide  (TRAC-WSMR,  Simulation 
Support  Division  III,  29  June  1987);  CASTFOREM  Cookbook . 3  (TRAC-WSMR,  Simula¬ 
tion  Support  Division  III,  6  August  1985);  and  personal  interview  between  Mr. 
Richard  Taylor,  ESC  and  Messrs.  Freeberg,  Mackey,  Champion,  and  Denney  of 
TRAC-WSMR  on  16  November  1987. 
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A  SUMMARY  OF  CASTFOREM,  VIC,  &  FORCEM  TERRAIN  PARAMETERS 


CASTFOREM 

VIC 

FORCEM 

STANDARD  GRID  CELL 
RESOLUTION 

100  m 

4  km 

10  km 

TYPICAL  AREA  OF 
OPERATION 

12  -  20  km 

150  x  150  km 

irregular 
( theater 
dependent) 

TERRAIN  ATTRIBUTES 
MODELED  * 

elevation 
vegetation 
built-up  areas 
canopy  closure 

elevation 
vegetation 
built-up  areas 

elevation 

cross-country 
mobility  (CCM) 

traff icability 

movement 
capability 
in  &  out  of 
cells 

roads 

rivers 

obstacles 

roads 

rivers 

obstacles 

LOC  networks 

Since  each  model  has  its  own  categories  and  classifications,  this 
is  only  a  rough  outline  of  the  features  covered  by  the  models. 
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modules  are  supported  by  various  data  types  and  data  files.  The  data  types 
and  data  files  are  used  as  reference  points  for  the  DTD  requirements  discus¬ 
sion. 

a.  DTD  Representation.  CASTFOREM  represents  terrain  as  square 

cells.  The  size  of  there  cells  is  uniform  within  a  terrain  data  set;  however, 
the  size  of  the  cell  can  be  changed  to  use  different  terrain  data  sets  for 

different  studies.  Cells  with  25-,  50- ,  and  100-meter  sides  have  been  used  in 

the  past.  100-meter  grid  cells  are  most  often  used  because  of  the  long  run 
times  involved  with  higher  resolution  grid  cells,  and  the  limited  availability 
of  higher  resolution  DTD  to  supply  the  model .  There  are  nine  terrain  attri 
butes  for  each  cell  that  define  roads,  surface  features,  vegetation  or  built- 
up  area  heights,  canopy  closure,  hydrography  (rivers),  cross-country  movement 
(CCM)  dry,  CCM  wet,  elevation,  and  obstacles  within  that  cell.  One  value  is 
assigned  for  each  of  the  terrain  attributes  within  a  cell.  This  means  tha*- 

the  vegetation  is  of  one  uniform  type,  the  elevation  is  of  one  height,  and  the 

CCM  is  of  one  value  for  the  entire  terrain  cell.  So  far,  all  the  terrain  sets 
used  by  CASTFOREM  have  gotten  input  for  these  terrain  attributes  from  the 
ARTBASS  data  base.  Besides  setting  the  grid  cell  size,  the  user  sets  the  size 
of  the  area  of  operation  (AO).  AOs  as  small  as  6  x  11  kilometers,  and  as 
large  as  20  x  20  kilometers  have  been  used,  with  the  norm  around  12  x  20 
kilometers.  This  is  roughly  equivalent  to  the  area  of  an  M745  series  1:50,000 
scale  topographic  line  map  of  Germany. 

b.  Off-line  DTD  requirements.  Before  a  CASTFOREM  combat  simulation 
can  begin,  the  user  is  required  to  prepare  the  battlefield.  One  step  in  this 
preparation  is  to  establish  the  physical  layout  of  the  battlefield  using  DTD. 
This  is  called  off-line,  pre-processed  terrain  data.  This  pre-processing  of 
DTD  is  over  and  above  the  actual  DTD  requirements  of  the  model  itself.  For 
example,  a  manual  intelligence  preparation  of  the  battlefield  (IPB)  process  is 
performed  based  on  knowledge  of  the  battlefield  similar  to  that  required  of  a 
battlefield  commander  preparing  for  actual  battle.  This  is  done  before  the 
actual  combat  simulation  run  is  performed,  and  uses  terrain  information  in 
either  digital  or  analog  form  as  a  basis  for  decisions.  Based  on  this  terrain 
knowledge,  the  user  specifies  the  value  of  the  input  variables  used  in  the 
simulation  model  as  discussed  below. 
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(1)  Maneuver  Control  Points  (MCPs) .  An  MCP  is  nothing  more 
than  a  battlefield  coordinate  (X,  Y,  and  Z)  that  has  been  given  a  unique 
numeric  name.  Movement  of  both  ground  and  air  vehicles  is  accomplished  over 
movement  networks  which  are  composed  of  linked  MCPs.  These  MCPs  usually 
correspond  to,  or  are  based  upon  established  road  or  transportation  networks 
provided  by  DTD  or  manual  map  analysis. 

(2)  Avenues  of  Approach  (AOPs) .  An  AOP  consists  of  MCPs  that 
will  represent  a  route  of  maneuver.  The  decision  to  establish  AOPs  is  based 
on  terrain  intelligence  that  is  provided  prior  to  the  simulation  run,  espe¬ 
cially  line  of  sight  (LOS)  analysis.  The  LOS  is  performed  off-line  prior  to 
the  simulation,  and  requires  use  of  data  provided  from  the  ARTBASS  DTD  set  or 
a  manual  process  to  produce  comparable  LOS  information.  Routes  for  avenues  of 
approach  are  selected  to  minimize  an  attacking  unit's  exposure  to  direct  fire 
systems  as  much  as  possible. 

(3)  Battle  Positions  (BPs)  and  Firing  Points  (FPs) .  A 
CASTFOREM  BP  consists  of  one  or  more  firing  positions;  for  moving  units  it 
also  includes  a  start  point  (SP)  and  a  release  point  (RP) .  When  choosing 
static  positions  such  as  FPs  within  BPs,  an  off-line,  line-of-sight  analysis 
must  be  used  to  ensure  that  the  unit  using  the  position  can  actually  see  the 
areas  of  interest,  as  well  as  find  out  what  it  cannot  observe.  This  off-line 
analysis  is  done  prior  to  the  combat  simulation  run  using  DTD  supplied  by  the 
ARTBASS  data  base. 

c.  On-line  DTD  requirements.  The  major  data  types  within  CASTFOREM 
that  use  DTD  are  highlighted  in  the  following  paragraphs.  The  various  data 
types  and  data  files  are  referred  to  by  the  abbreviations  and  labels  used  in 
CASTFOREM . 

(1)  Battlefield  data  (BFLD-DATA) .  The  purpose  of  this  data 
type  is  to  provide  some  of  the  initial  physical  battlefield  parameters  of  the 
model.  Several  DTD  requirements  are  found  in  this  data  type.  DTD  require¬ 
ments  are  found  in  data  files  BF  10,  BF  21/22,  and  BF  23. 

(a)  Data  file  BF  10  is  used  to  designate  the  moisture 
condition  (wet  or  dry)  and  the  time  of  the  year  (summer  or  winter) .  This  data 
must  be  specified  by  the  user  prior  to  the  simulation  run. 

(b)  Data  file  BF  21/22  is  used  to  designate  one  of  16 
surface  features  (i.e.,  agriculture,  brushland,  coniferous  forest,  orchard, 
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grassland,  open  water,  built-up  areas,  etc.),  their  height,  and  their 
foliation  during  summer  and  winter  seasons.  The  user  selects  the  season,  but 
the  feature  data  is  extracted  from  the  ARTBASS  DTD. 

(c)  Data  file  BF  23  pertains  to  obstacles  and  the  obsta¬ 
cles'  minimum  heights.  Five  categories  of  obstacles  are  represented:  road 
and  railroad  cuts  and  fills,  natural  linear  features,  walls  and  fences,  other 
man-made  linear  obstacles,  and  military  obstacles.  This  input  data  is 
extracted  from  the  ARTBASS  DTD. 

(2)  Terrain  Data  (TERRAIN- DATA) .  The  purpose  of  the  terrain 
data  type  is  to  provide  digitized  terrain  data  to  CASTFOREM  modules.  The 
terrain  data  files  are  provided  via  nine  pre-processed  binary  files  which  are 
prepared  using  data  from  the  ARTBASS  data  base.  Battlefield  data  descriptions 
(BFLD-DATA  discussed  above)  must  have  been  input  prior  to  reading  the  terrain 
files,  and  the  descriptors  on  the  header  of  each  terrain  binary  file  must 
match  the  descriptors  for  the  battlefield  data.  Each  binary  terrain  file 
consists  of  many  data  elements.  The  data  elements  related  to  DTD  requirements 
call  for  nine  terrain  codes  for  each  cell:  road  type,  surface  features, 
vegetation  or  built-up  area  height,  canopy  closure,  hydrography  (rivers),  CCM 
(dry),  CCM  (wet),  elevation  (m) ,  and  obstacles.  These  data  elements  have  been 
supplied  in  the  past  by  ARTBASS  DTD. 

(3)  Object  library  (OBJECT-LIB).  The  purpose  of  the  object 
data  type  is  to  insert  objects  that  are  used  by  the  engineer  and  CSS  modules. 
Objects  such  as  craters  and  various  types  of  minefields  can  be  placed  by  the 
user  into  the  combat  simulation  run  using  this  data  type.  Two  terrain 
requirements,  soil  strength  and  traf f icability ,  are  used  when  defining  these 
object  types.  Currently,  these  data  elements  are  not  being  used  and  are  set 
to  zero. 

(4)  Type  of  Units  (TYPE-UNITS) .  The  purpose  of  this  data  type 
is  to  define  the  generic  units  on  the  battlefield.  The  unit's  size,  vulner¬ 
ability,  sensors,  personnel,  fuel  capacity,  etc.,  are  described  in  this  data. 
Of  the  variables  that  must  be  defined  for  each  unit,  two  are  DTD-related: 

the  TU30  card  (cross-country  speed  data)  and  the  TU32  card  (road  speed  data) . 
The  TU30  card  sets  the  cross-country  speed  for  each  unit  based  on  its  current 
grid  cell  location.  The  cross-country  movement  (CCM)  speeds  are  obtained  from 
ARTBASS  DTD.  The  TU32  card  sets  the  road  speed  appropriate  for  the  unit's 
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current  grid  cell  location.  Currently,  road  speed  data  are  manually  input 
based  on  a  map  analysis  of  the  road  network  in  the  area  being  modeled. 

(5)  Line  of  Sight  (LOS).  Intervisibility,  or  LOS  is  computed 
for  two  purposes:  placement  of  BPs  and  FPs  (see  the  discussion  of  off-line 
DTD  requirements),  and  LOS  detection  between  an  observer  and  target.  LOS 
detection  algorithms  are  embedded  in  the  computer  code  and  are  used  on  a 
continuous  basis  throughout  the  battle  simulation.  LOS  is  computed  utilizing 
digitized  terrain,  taking  into  consideration  ground  elevations  and  vegetation 
heights  for  each  grid  cell,  and  other  factors  such  as  height  of  weapon  or 
sensor,  and  obscuration  data.  CASTFOREM  calculates  LOS  as  uniform  anywhere 
within  a  terrain  cell.  This  means  if  LOS  is  possible  from  any  point  within 
the  cell,  then  all  points  within  that  cell  will  be  considered  to  have  LOS. 

d.  Availability  of  DTD  for  CASTFOREM.  CASTFOREM  is  currently  using 
only  ARTBASS  and  WES  data  sets.  DTD  coverage  suitable  for  CASTFOREM  to  use  is 
available  for  portions  of  the  Federal  Republic  of  Germany  (FRG) ,  Korea,  Egypt, 
Jordan,  and  Costa  Rica  (see  Appendix  E-l).  Additional  coverage  will  become 
available  as  new  ARTBASS  data  sets  are  produced  under  contract  over  the  next 
three  years.  The  adequacy  of  the  available  DTD  to  support  CASTFOREM  terrain 
requirements  is  discussed  in  paragraph  15. 

13.  VIC  Model  Description.  This  evaluation  is  based  on  information 
obtained  from  the  VIC  model  documentation  and  interviews  with  persons  familiar 
with  the  VIC  model. ^  VIC  is  a  two-sided  deterministic  simulation  of  combat  in 
a  combined-arms  environment.  It  represents  land  and  air  forces  at  the  US  Army 
corps  level  with  a  commensurate  enemy  force  in  a  mid- intensity  battle.  The 
model  is  event-stepped  for  maneuver  elements  and  time-stepped  for  calculation 
of  support  effects.  It  may  be  run  in  either  an  interruptible  mode,  or  in  a 
systematic  batch  mode.  It  has  a  series  of  pre-processors  for  constructing 
input  data  files  and  a  comprehensive  post-processor.  VIC  is  executed  through 
a  series  of  modules  which  each  represent  a  major  function  on  the  battlefield 
(see  Figure  E-3). 


° Vector  in  Commander  (VIC)  Combat  Simulation ,  Executive  Summary,  Model 
User's  Guide,  Post-processor  User's  Guide,  and  VIC  Interactive  Pre -processor 
(VIP)  User's  Guide,  draft  (TRAC-WSMR-TD,  June  1987).  Vector  in  Commander 
(VIC)  Combat  Simulation ,  Data  Input  and  Methodology  Manual,  draft  (TRAC-WSMR- 
TD,  June  1987),  and  personal  interview  between  Mr.  Richard  Taylor,  ESC,  and 
Messrs.  Gamble,  Porter,  Lankford  of  TRAC-WSMR  on  16  November  1987. 
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VIC  MODULES 


NUMBER 

TITLE 

ABBREVIATION 

1 

SYSTEM  SPECIFICATIONS 

SS 

2 

GLOBAL  GROUND 

GG 

3 

GROUND  MOVEMENT 

GM 

4 

ARTILLERY 

AT 

5 

GLOBAL  AIR 

GA 

6 

AIR  MAINTENANCE 

AM 

7 

AIR-TO-GROUND  ATTACK 

AG 

8 

AIR  INTELLIGENCE 

AI 

9 

GROUND  INTELLIGENCE 

Cl 

10 

FUSION  INTELLIGENCE 

FI 

11 

AIR  DEFENSE 

AD 

12 

DEFENSE  SUPPRESSION 

DS 

13 

ELECTRONIC  WARFARE 

EW 

14 

CHEMICAL 

CH 

15 

open  for  expansion 

16 

GRAPHICS  DATA  MODULE 

GX 

17 

WEATHER  DATA 

WT 

18 

TERRAIN  AND  BARRIERS 

TB 

19 

DECISION  TABLES 

DT 

20 

HELICOPTERS 

HC 

21 

LOGISTICS 

LO 

22 

COMMUNICATIONS 

CO 

23 

RETURN  TO  DUTY 

RD 

24 

POST- PROCESSOR 

PT 

25 

MINEFIELDS 

MF 

26 

AIR-TO-AIR 

AA 

27 

FRONT  LINE  DETAILED  ATTRITION 

FL 

28 

SMOKE 

SM 

29 

ENGINEERS 

EN 

Figure  E-3 
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a.  DTD  Representation.  Terrain  is  input  to  VIC  in  square  grid 
cells.  The  data  required  for  each  cell  represents  four  major  terrain  factors: 
vegetation,  relief,  area  obstacles,  and  linear  obstacles.  These  factors  act 
in  combination  with  maneuver  unit  factors  to  predict  traf f icability ,  line  of 
sight,  and  visibility.  The  user  of  the  model  may  specify  the  size  of  the  grid 
cell;  4  kilometers  by  4  kilometers  is  normally  used.  Special  programs  are 
provided  in  a  pre-processor  that  will  process  digitized  terrain  at  typical  DTD 
resolutions  (e.g.,  25m,  50m,  100m)  and  synthesize  it  into  the  desired  model 
cell  resolution,  in  this  case  4  kilometers  by  4  kilometers.  For  example, 
previous  runs  of  VIC  have  used  a  DTD  set  prepared  by  a  contractor,  which 
covered  an  area  in  West  Germany  that  contained  high- resolution  data.  In 
addition  to  setting  the  grid  cell  size,  the  user  sets  the  size  of  the  AO. 
Several  sizes  have  been  used  in  the  past.  A  150  km  by  600  km  area  is  a 
typical  corps  AO  size  used  in  VIC.  This  is  about  equivalent  to  six  DMA 
1:250,000  scale  topographic  line  maps.  The  origin  for  the  X  and  Y  axes  is 
determined  by  the  user;  the  model  will  then  read  the  location  data  in  either  X 
and  Y  coordinates  or  military  UTM  coordinates.  Like  CASTFOREM,  VIC  requires 
users  to  identify  and  define  various  terrain  elements  prior  to  running  the 
simulation.  Pre-processed  DTD  features  are  used  for  selecting  avenues  of 
approach,  tactical  areas,  main  supply  routes,  and  barrier  locations. 

b.  Off-line  DTD  requirements.  Preparing  a  VIC  combat  simulation 
requires  tne  use  of  off-line,  pre-processed  terrain  data  similar  to  CASTFOREM. 
This  pre-processed  DTD  is  over  and  above  the  actual  DTD  requirements  of  the 
model  itself.  A  user  must  prepare  the  battlefield  based  upon  a  conceptual 
scenario.  This  is  done  before  the  actual  combat  simulation  is  performed. 

This  DTD  pre-processing  takes  place  in  the  VIC  Interactive  Preprocessor  (VIP) . 
VIP  constructs  data  input  files  and  uses  terrain  information  in  digital  form 
as  a  basis  for  graphical  display.  Based  upon  this  terrain  knowledge,  the  user 
selects  required  variables  which  are  used  in  the  simulation  model  and  are 
addressed  as  a  part  of  the  VIP  menu  structure  below. 

(1)  DTD  is  used  by  VIP  to  form  the  terrain  displays  that  aid  in 
preparing  input  to  VIC.  No  one  particular  digital  data  base  has  been  used 
exclusively;  instead  the  best  data  available  is  used  to  cover  the  area  of 
operations.  As  an  example,  the  DTD  provided  by  a  contractor  included  a  LOC 
network  data  base,  a  surface  feature  data  base,  and  a  terrain  elevation  data 


base.  The  LOC  network  data  base  consisted  of  1.4  vector  formatted  data 
features:  autobahns,  main  roads,  secondary  roads,  lightly  surfaced  roads, 

railroad  lines,  ferries,  fords,  heavy  bridges,  dams,  road  tunnels,  rail 
tunnels,  and  three  classes  of  rivers.  The  surface  feature  data  base  consists 
of:  open  areas,  forest,  urban,  undefined  areas,  marsh,  standing  water,  and 

heath.  The  terrain  elevation  data  base  was  created  from  DMA  DTED  leve]  I 
(rather  than  from  the  contractor  DTD) .  This  information  was  formatted  to 
supply  the  required  vegetation,  relief,  area  obstacle,  and  linear  obstacle 
data  requirements  of  VIC. 

(2)  The  VIP  menu  (Figure  E-4)  is  used  to  build  various  parts  of 
a  scenario  and  create  VIC  input  files.  Several  of  these  use  DTD  as  a  basis 
for  decisions . 

(a)  Path  point,  route  plan,  network,  and  logistics  menus 
allow  the  user  to  select  and  plan  general  AOPs ,  and  transportation  networks 
for  combat  and  CSS  units  to  follow.  These  menus  use  DTD,  particularly 
transportation  and  elevation  data,  as  a  decision  aid.  Five  classes  of 
transportation  data  (autobahns,  main  roads,  secondary  roads,  fair  weather 
road,  railways)  and  digital  elevation  data  have  been  used  in  the  past. 

(b)  Barrier  and  line  obstacle  menus  allow  the  user  to 
create  and  deploy  area  obstacles  (sometimes  referred  to  as  barrier  obstacles) 
and  line  obstacles  (sometimes  referred  to  as  linear  obstacles) .  The  user 
defines  obstacles  based  on  the  terrain  displayed  in  VIP.  The  ability  to 
overlay  area  obstacles  on  the  terrain  was  developed  to  allow  the  portrayal  of 
features  such  as  urban  areas  and  nuclear,  biological,  and  chemical  (NBC) 
contaminated  areas.  However,  VIC  now  allows  each  terrain  grid  square  to  have 
its  own  traf f icability  code,  and  area  obstacles  are  no  longer  treated  as  an 
overlay  to  the  terrain.  Instead  they  are  represented  by  the  traf f icability 
and  visibility  codes  given  to  individual  terrain  g^id  squares.  Line  obstacles 
are  still  input  as  line  segments  that  are  overlayed  on  the  terrain  independent 
of  the  underlying  grid  square  system.  This  allows  for  accurate  positioning  of 
natural  and  man-made  linear  obstacles,  such  as  embankments  and  antitank 
ditches,  without  being  restricted  to  the  grid  pattern. 

(3)  In  addition  to  using  DTD  in  VIP  (to  support  the  development 
of  VIC  input  files),  DTD  must  also  be  processed  to  provide  the  terrain  grid 
square  data  used  by  VIC  in  the  actual  execution  of  the  model. 
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VIP  MAIN  MENU  STRUCTURE 


-  -  KEYWORD 

-  -  HELP 

--  UNIT  ID  GEN 


--  UNIT  MENU  --  PATH  PT  MENU  --  | 

I 

--  SUBORDINATE  MENU 
--  COMMUNICATIONS  MENU 

--  RT  PLAN  MENU  -  . 

--  MINEFIELD  MENU 
--  BARRIER  MENU 
--  LINE  OB  MENU 

--  NETWORK  MENU  |  LOGISTICS  MENU 


--  GRAPHICS 

-  -  PARAMETERS 
--  CHANGE  PLANE 

-  -  PLAYBACK 


--  UTILITY  MENU  -- 


--  GRAPHIC 
--  TERRAIN 
--  MENU 
--  DEFINE 
SLIDE 


Figure  E-4 
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RT  PLAN  MENU 


E-2 


s 


c.  On-line  DTD  requirements.  VIC  is  executed  through  a  series  of 
modules  (Figure  E-3),  each  of  which  represents  a  major  function  on  the  bat¬ 
tlefield.  These  modules  consist  of  data  requirements,  which  are  further 
subdivided  into  data  segments.  Each  segment  represents  a  block  of  data  which 
is  required  by  VIC.  The  modules  and  data  segments  are  referred  to  by  the 
abbreviations  and  labels  used  in  VIC. 

(1)  Terrain  and  Barriers  (TB) .  There  are  four  segments  in  the 
TB  module  that  require  the  direct  use  of  DTD.  These  segments  load  and  list 
all  data  associated  with  terrain  and  barriers. 

(a)  TB-ONE  contains  basic  information  on  the  extent  and 
classification  of  vegetation.  There  is  no  inherent  limitation  to  the  number 
of  vegetation  classes  VIC  can  play,  but  currently  four  classes  are  portrayed: 
dense  forest,  light  vegetation,  grassland,  and  urban  areas.  This  segment 
provides  vegetation  data  that  is  used  in  several  modules. 

(b)  TB-TWO  performs  four  major  functions  and  uses  DTD 

elevation  data  as  its  basic  source.  First,  it  classifies  relief  into  major 
categories:  plains,  hills,  and  mountains  using  a  VIC  terrain  classification 

algorithm  (see  glossary  for  further  explanation).  Second,  it  performs 
visibility  mapping  which  combines  the  vegetation  type  (taken  from  TB-ONE)  and 
the  relief  type  into  three  visibility  levels:  good,  fair,  or  poor.  Third,  it 
performs  traf f icability  mapping  which  also  combines  relief  and  vegetation  into 
three  traf f icability  levels  of  good,  fair,  and  poor.  Finally,  this  segment 
performs  LOS  and  exposure  distance  mapping.  The  LOS  parameter  is  used  to 
compute  the  fractional  LOS  in  that  type  of  terrain.  The  mean  exposure  length 
is  used  to  determine  the  average  time  a  target  remains  visible. 

(c)  TB-THREE  allows  the  user  to  place  area  obstacles  on 
the  current  terrain  mapping.  There  is  no  inherent  limitation  to  the  number  of 
area  obstacle  classes  VIC  can  play,  but  seven  types  of  area  barriers  are 
identified  in  the  documentation:  rivers,  passable  features,  impassable 
features,  urban  areas,  chemical-,  biological-,  and  nuclear-contaminated  areas. 
This  segment  is  not  being  used  at  this  time.  Instead  area  obstacles  are 
represented  through  the  traf f icability  codes  assigned  to  each  grid  square. 

(d)  TB-FOUR  allows  linear  obstacles  to  be  placed  on  the 
battlefield.  There  is  no  inherent  limitation  to  the  number  of  linear  obstacle 
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classes  VIC  can  play,  but  currently  four  major  types  have  been  designated: 
rivers,  canals,  tank  ditches,  and  embankments. 

(2)  Ground  Movement  (GM) .  Segment  GM-THREE  computes  six 
distinct  data  variables  that  are  based  upon  information  supplied  in  the  TB 
module.  The  four  major  variables  affecting  the  movement  of  ground  com bat 
units  are:  a  combined  traf f icability  table,  an  opposed  speed  table,  combined 
weather/barrier  visibility  table,  and  a  combined  environmental/obscurant 
visibility  table. 

(a)  The  combined  traf f icability  table  is  a  3  by  3  table 
which  is  used  to  combine  the  traf f icability  due  to  the  weather  (good,  fair, 
and  poor)  with  the  traf f icability  due  to  terrain  (good,  fair,  poor)  to  produce 
an  overall  traff icability  (good,  fair,  and  poor).  This  overall  traff icability 
is  then  used  as  input  to  the  opposed  speed  table. 

(b)  The  opposed  speed  table  is  a  2  by  3  by  11  table  which 
is  used  to  determine  the  speed  of  a  moving  unit  when  in  contact  with  an 
opposing  force.  Opposed  movement  is  indexed  by  mobility  (l=mounted,  2=dis- 
mounted) ,  traf f icability  (good,  fair,  and  poor  from  the  combined  traf- 
ficability  table  above) ,  and  kill  ratios  computed  from  opposing  forces  in 
contact . 

(c)  The  combined  weather/barrier  visibility  table  is  a 

3  by  3  table  used  to  combine  the  visibilities  due  to  weather  (good,  fair,  and 
poor)  and  terrain  (good,  fair,  and  poor)  into  an  overall  environmental 
visibility  of  good,  fair,  and  poor. 

(d)  The  combined  environmental/obscurant  visibility  table 
is  a  3  by  3  table  used  to  combine  the  environmental  visibility  with  the 
visibility  level  due  to  smoke,  dust,  and  debris  to  form  an  overall  visibility. 

(3)  Global  ground  (GG)  .  Segment  G«^ -ONE  contains  two  data  vari- 
aoles  that  are  DTD-related  but  are  user  input. 

(a)  The  maximum  day  speed  is  used  to  compute  unit  travel 
speeds.  It  is  expressed  in  kilometers/hour  which  provides  the  speed  for 
unopposed  movement  during  daylight  hours;  it  is  also  used  as  input  to  opposed 
speed  calculations.  Currently,  this  variable  is  user-specified.  VIC  does  not 
use  CCM  speed  or  on  road  speeds  derived  from  DTD  to  calculate  this  variable. 

(b)  Maximum  night  speed.  The  discussion  in  the  previous 
section  on  maximum  day  speed  applies  for  night  speed  also. 


(4)  Logistics  (LO) .  Segment  LO-THREE  contains  three  data  vari¬ 
ables  that  are  affected  by  transportation  data  contained  in  DTD.  All  are  used 
to  determine  the  effectiveness  of  the  road  network  for  logistics  operations. 
All  codes  are  currently  input  by  the  user.  The  transportation  element  in  the 
DTD  set  is  currently  not  used  as  an  input  source. 

(a)  The  road  surface  code  requires  information  on  the  road 
surface  that  can  be  obtained  from  the  DTD.  Four  classes  are  described: 
concrete,  bituminous,  gravel,  and  dirt. 

(b)  The  road  width  code  allows  the  choice  of  two  values 
for  road  width:  roadways  greater  than  24  feet  wide  and  roadways  less  than  24 
feet  wide. 

(c)  The  road  terrain  code  requires  that  four  types  of 
terrain  be  characterized:  flat,  rolling  hills,  hills  with  curves,  and  moun¬ 
tainous  with  the  type  of  terrain  affecting  the  road  speed. 

(5)  Artillery  (AT).  AT-THREE  allows  the  evaluation  of  the 
effects  of  terrain  on  lethal  areas  of  artillery-round  impact.  This  is  done 
through  the  Minimum  Lethal  Area  Factor  Data  input  variable.  This  factor 
states  that  certain  munitions  will  not  be  fired  into  a  terrain  type  that  has 
an  associated  terrain  factor  less  than  this  parameter.  Perfect  terrain 
(plains  with  grassland)  has  a  factor  of  1.0. 

(6)  Air-to-ground  (AG).  AG-THREE  allows  the  evaluation  of  the 
effects  of  terrain  on  the  probability  of  detecting  a  target.  Terrain  can 
obscure  or  partially  obscure  geographic  areas.  This  is  done  through  the 
Probability  of  Target  Detection  Data  input  variable.  This  parameter  is  a 
function  of  visibility  (good,  fair,  and  poor)  and  a  target  priority. 

d.  Availability  of  DTD  for  VIC.  Currently,  DTD  that  can  satisfy 
VIC  requirements  is  available  in  two  regions  of  the  world:  FRG  and  Korea. 

VIC  is  using  the  best  available  data  for  the  areas  it  is  now  simulating.  The 
adequacy  of  the  available  DTD  coverage  to  support  future  VIC  terrain  require¬ 
ments  is  discussed  in  paragraph  16 . 

14.  FORCEM  Model  Description.  This  evaluation  is  based  on  a  review  of 
the  FORCEM  model  documentation  and  interviews  with  persons  familiar  with  the 


model. ^  FORCEM  is  a  deterministic,  average  value  model  which  is  fully  auto¬ 
mated.  There  are  no  player  interactions  while  the  model  is  running.  It  is  a 
completely  two-sided  model  that  operates  on  a  time-step  basis,  representing 
the  campaign  in  12 -hour  time  slices.  Headquarters  at  corps,  Army,  and  theater 
levels  are  represented.  For  each  time  step,  the  model  cycles  through  a 
process  to  develop  the  combat  situation  for  both  sides;  it  makes  decisions 
regarding  actions  to  be  taken  by  subordinate  elements;  it  develops  the  combat 
and  combat- support  activities  resulting  from  the  decisions  of  both  sides;  it 
performs  post-cycle  status  updates;  and  it  produces  output  data  for  that  time 
period. 

a.  DTD  Representation.  FORCEM  represents  terrain  as  square  cells. 
The  size  of  these  cells  is  uniform  within  a  terrain  data  set;  however,  the 
size  of  the  cell  can  vary.  Formerly  30  by  30  km  cells  were  used,  but  10  by  10 
km  cells  are  now  being  used.  Each  terrain  cell  is  assigned  the  dominant 
terrain  codes  for  each  of  eight  directions  into  and  out  of  the  cell.  Nine 
terrain  types  can  be  represented:  oceans/lakes ,  low  mountains,  high  moun¬ 
tains,  rivers,  cities,  forests,  roads,  AOPs,  and  open  terrain.  Thus,  each 
direction  through  a  cell  is  digitized  and  coded  according  to  the  predominant 
natural  or  man-made  feature  in  that  cell.  This  procedure  results  in  a 
detailed  movement  capability  map  that  represents  the  difficulty  of  movement  in 
each  of  the  eight  directions  through  the  square.  All  runs  of  FORCEM  have 
utilized  terrain  data  that  was  manually  encoded  from  map  sheets  at  the 
1:1,000,000  or  1:2,000,000  scale.  DTD  currently  exists  for  the  European, 
Korean,  and  Southwest  Asia  theaters.  Superimposed  on  the  terrain  grid  are 
logistics  networks.  Three  types  of  logistics  networks  are  represented:  road, 
railway,  and  waterways.  Major  items  of  equipment  and  personnel  flow  along 
these  networks.  Materiel  and  personnel,  as  well  as  units  arrive  in  the  theater 
of  operations  through  ports  (both  sea  and  air) . 

b.  Off-line  DTD  requirements.  Preparing  a  FORCEM  combat  simulation 
requires  the  use  of  off-line,  pre-processed  terrain  data  similar  to  that  of 


'FORCEM  Evaluation  Model  Briefing  Slides  (CAA,  March  1985);  Command  and 
Control  in  the  Force  Evaluation  Model  (CAA,  14  January  1986);  FORCEM  Combat 
Service  Support  Module  (CAA,  20  February  1986);  The  FORCEM  Fire  Support  Module 
(CAA,  May  1986)  and  personal  interview  between  Messrs.  Taylor,  Reynolds,  and 
Halayko  of  ESC,  and  Mr.  Wallace  Chandler,  CAA  on  23  November  1987. 


CASTFOREM  and  VIC.  A  user  must  prepare  the  battlefield  based  upon  an  opera¬ 
tional  plan.  This  is  done  before  the  actual  combat  simulation  is  performed. 
The  battlefield  representation,  using  terrain  information  in  digital  form,  is 
a  basis  for  decisions  in  the  model.  DTD  is  encoded  by  hand  at  CAA  from 
tactical  pilotage  charts  (TPCs) ,  operational  navigational  charts  (ONCs) ,  and 
global  navigation  charts  (GNCs) ,  which  are  published  at  DMA.  These  CAA 
digital  terrain  files  are  then  used  as  terrain  input  files  to  the  model.  As 
mentioned  previously,  the  terrain  in  FORCEM  now  is  represented  using  10  by  10 
km  grid  cells.  The  terrain  features  can  be  categorized  into  two  functional 
areas:  movement  enhancements,  and  movement  impediments.  The  movement  impedi¬ 

ments  are  features  such  as  hills,  mountains,  forests,  urban  areas,  rivers, 
lakes,  and  canals.  Movement  enhancement  features  such  as  roads  and  railways 
are  also  represented.  Other  features  such  as  ports  (airports  and  seaports) 
are  also  input  prior  to  simulation  by  the  user  from  map  information. 

c.  On-line  DTD  requirements.  Terrain  and  its  representation  in 
FORCEM  is  centered  around  a  single  theme:  movement  --of  units,  personnel, 
equipment,  and  logistics.  This  movement  centers  around  two  categories  of 
terrain  features:  LOCs  and  major  surface  features.  This  discussion  centers 
on  these  features  and  how  they  are  used  in  the  model. 

(1)  Lines  of  communication  (LOCs). 

(a)  Roads,  railways,  and  waterways  are  the  conduit  for 
convoys,  barges,  and  trains.  These  LOCs  are  encoded  via  the  logistics  net¬ 
works.  Units,  supplies,  and  equipment  moving  along  these  networks  are  subject 
to  interdiction  and  attrition.  However,  the  networks  themselves  are  not 
subject  to  damages.  FORCEM  does  not  distinguish  certain  features  along  the 
LOC  infrastructure.  For  example,  bridges  and  tunnels  are  not  represented,  nor 
are  road  classes  (e.g.,  autobahn  or  two-lane  roads).  Petroleum,  oil,  and 
lubricants  (POL)  pipelines  have  been  classified  as  a  LOC  feature  in  the  past. 
However,  FORCEM  currently  does  not  represent  POL  pipelines  as  a  logistics 
network  feature.  POL  pipelines  (PPL)  are  assumed  regardless  of  the  lack  of 
in-country  facilities. 

(b)  From  a  functional  standpoint,  aerial  ports  of  entry 
(airports)  and  seaports  are  identical.  Seaports  and  airports  are  not 
extracted  from  a  digital  LOC  file,  but  selected  and  input  by  the  user  prior  to 
simulation.  Materiel  and  personnel  enter  the  theater  through  seaports  and 
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airfields.  Ports  are  FORCEM  "units"  and  have  defined  capacities  and  capabili¬ 
ties  that  can  be  subject  to  damage.  Damage  to  ports  is  represented  as  a 
function  of  the  casualties  to  port  personnel.  Port  facilities  such  as  piers, 
quays,  cranes,  and  covered  storage  are  not  explicitly  represented,  so  facility 
damage  is  not  directly  measurable. 

(2)  Major  surface  features.  There  are  eight  major  surface 
terrain  features  that  can  be  represented  in  FORCEM:  low  mountains,  high 
mountains,  lakes/rivers,  urban  areas,  forests,  high-speed  roads,  AOPs ,  and 
open  terrain.  A  lack  of  other  vegetation  classes  makes  it  difficult  to 
accurately  represent  the  mobility  impacts  of  other  types  of  terrain  such  as 
marshes  and  swamps . 

d.  Availability  of  DTD  for  FORCEM.  Adequate  DTD  is  currently 
available  from  DMA  to  satisfy  FORCEM 's  low  resolution  terrain  requirements. 

The  adequacy  of  the  available  DTD  to  support  future  FORCEM  terrain  require¬ 
ments  is  discussed  in  paragraph  17. 


IV.  CONCLUSIONS 


15.  CASTFOREM.  DTD  is  used  off-line  to  make  IPB  decisions  prior  to 
running  CASTFOREM,  especially  to  plan  LOS,  MCPs ,  AOPs ,  and  BPs .  DTD  is  used 
on-line  to  provide  various  model  parameters  for  the  computation  of  LOS  and 
traff icability .  ARTBASS  DTD  is  currently  used  to  satisfy  the  majority  of 
CASTFOREM' s  DTD  requirements  (100-meter  cell  resolution). 

a.  CASTFOREM  could  make  better  use  of  existing  DTD  sources  by 
replacing  some  data  that  is  now  manually  input  with  data  that  is  automatically 
processed  from  available  DTD  sources  (some  specific  examples  are  given  in 
Section  V.,  RECOMMENDATIONS). 

b.  The  need  for  DTD  to  support  CASTFOREM  is  dependent  on  the 
studies  that  will  use  the  model.  However,  ESC's  assessment  of  how  CASTFOREM 
is  used  leads  us  to  the  conclusion  that  existing  DTD  coverage,  along  with  the 
additional  areas  being  produced  in  ARTBASS  format  through  ETL  and  WES,  will  be 
adequate  to  meet  most  CASTFOREM  requirements.  To  use  CASTFOREM  to  test 
battalion  and  smaller  unit  doctrine,  tactics,  force  structure,  and  equipment, 
it  is  not  necessary  to  run  the  simulation  over  every  piece  of  terrain  in  the 
world  where  US  battalions  could  fight.  Except  for  special  studies  that  need 
to  play  a  specific  geographic  location  or  a  unique  type  of  terrain  for  which 
no  DTD  exists,  the  available  DTD  provides  an  adequate  sample  of  different 
terrain  types  to  represent  the  kinds  of  terrain  situations  US  forces  are 
likely  to  face. 

16.  VIC .  VIC  demonstrates  an  effective  use  of  relatively  high- 
resolution  DTD  as  an  off-line  decision  aid.  The  off-line  DTD  is  used  as  input 
to  a  preprocessor  that  develops  the  low- resolution  input  required  by  the  model 
itself  (e.g.,  100m  spacings  between  elevation  points  are  used  as  a  base  for 
terrain  classifications  of  plains,  hills,  and  mountains  in  low-resolution,  4 
km  cells) . 

a.  VIC  could  make  better  use  of  existing  DTD  sources  by  replacing 
some  data  that  is  now  manually  input  with  data  extracted  from  available  DTD 
sources  (some  specific  examples  are  given  in  Section  V.,  RECOMMENDATIONS). 

b.  The  need  for  DTD  to  support  VIC  is  dependent  on  the  specific 
studies  that  will  use  the  model.  If  VIC  is  used  only  to  study  broad  doctrine 
and  force  structure  questions,  then  a  small  array  of  terrain  data  sets  that 
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cover  the  general  types  of  terrain  US  corps  are  likely  to  have  to  fight  on,  is 
adequate  to  meet  VIC's  needs.  However,  middle  level  resolution  models  like 
VIC  can  and  are  used  to  analyze  specific  contingency  planning  issues.  To  be 
responsive  to  the  need  for  analysis  of  corps  operations  in  a  particular  area, 
DTD  must  be  available  for  that  specific  area.  The  current  delays  in  producing 
DTD  mean  that  terrain  coverage  requirements  must  be  planned  well  in  advance 
for  the  data  to  be  available  when  it  is  needed.  The  requirements  for  DTD  to 
support  VIC  are  not  sufficient  justification  to  generate  an  urgent  need  for 
new  DTD  production.  But,  the  terrain  areas  that  are  of  interest  to  the 
modeling  community  are  the  same  areas  where  DTD  is  needed  to  support  the 
fielding  of  new  Army  weapons  and  battlefield  command,  control,  communications, 
and  intelligence  (C^I)  systems.  VIC  users  must  be  aware  of  the  coverage  and 
formats  of  the  DTD  being  produced  for  these  new  systems  so  they  can  make  use 
of  it  in  VIC  when  it  becomes  available. 

17.  FORCEM.  DTD,  currently  used  by  FORCEM,  is  generated  manually  at 
extremely  low  resolutions  by  in-house  personnel  at  CAA  for  both  off-line 
decision  making  and  a  few  on-line  simulation  decisions. 

a.  This  in-house  manual  DTD  generation  could  be  eliminated  by 
developing  the  ability  to  use  existing  DTD  files  to  support  FORCEM  (this 
initiative  is  discussed  in  Section  V.,  RECOMMENDATIONS). 

b.  Until  CAA  develops  a  preprocessor  that  can  use  digitized  terrain 
input,  there  are  no  requirements  for  the  production  of  new  DTD  coverage  for 
FORCEM.  Once  a  preprocessor  is  developed,  the  available  DTED  and  DFAD 
coverage  will  satisfy  FORCEM  terrain  requirements.  However,  the  limitations 
of  DFAD  representation  of  LOC  networks  means  CAA  will  still  have  to  do  some 
manual  coding  of  LOC  information  until  DMA  produces  the  new  standard  DTD 
products . 


V.  RECOMMENDATIONS 


18.  Make  Increased  Use  of  DTD.  Each  of  the  models  examined  is  manually 
entering  terrain  data  that  could  be  obtained  from  existing  DTD  sources. 

a.  CASTFOREM  makes  good  use  of  DTD;  efforts  should  continue  to 
automate  the  extraction  of  additional  terrain  feature  data  from  existing  DTD 
files.  For  Example,  TRAC-WSMR  should: 

(1)  Use  ARTBASS  modified  unified  soil  classification  data  to 
determine  soil  strength  for  OBJECT-LIB  requirements. 

(2)  Use  ARTBASS  CCM  data  to  supply  traf f icability  data  for 
OBJECT-LIB  requirement. 

(3)  Use  WES-Mobility  AMM  data  to  provide  on-road  speed  data  to 
the  TU32  road  speed  card  via  the  road  code  attribute  for  each  cell . 

Currently,  ARTBASS  DTD  only  provides  road  classifications,  not  the  speed  for  a 
distinct  road  type. 

b.  VIC  and  its  preprocessor  VIP  make  good  use  of  DTD;  efforts 
should  continue  to  automate  the  extraction  of  additional  terrain  feature  data 
from  existing  DTD  files.  For  Example,  TRAC-WSMR  should: 

(1)  Use  WES-Mobility  AMM  DTD  to  derive  maximum  day  and  night 
speeds  (both  CCM  and  road  speeds)  in  the  GG  module. 

(2)  Use  WES-Mobility  AMM  DTD  to  supply  road  surface  codes,  road 
width  codes,  and  road  terrain  codes  for  the  LO  module. 

c.  FORCEM  uses  manually  generated  terrain  input;  efforts  should  be 
undertaken  to  automate  the  extraction  of  terrain  data  from  existing  DTD  files. 
To  reduce  this  manual  effort  CAA  should: 

(1)  Develop  an  off-line  DTD  preprocessor  (similar  to  VIP)  to 
prepare  terrain  input  for  FORCEM. 

(2)  Use  DMA's  DFAD  and  DTED  data  as  sources  of  DTD  to  satisfy 
current  FORCEM  requirements  and  to  open  the  way  for  new  standard  DTD 
(including  better  LOC  information)  to  be  used  in  the  future. 

19.  Make  Model  DTD  Compatible  With  Tactical  DTD.  The  generation  of  new 
DTD  should  be  driven  primarily  by  the  requirements  of  new  tactical  weapons  and 
C^I  systems,  not  by  model  requirements.  However,  the  areas  where  DTD  is 
needed  for  the  new  tactical  systems  are  also  the  areas  where  model  analysis 
will  be  needed.  Therefore,  when  DTD  is  produced  in  the  new  standard  formats 
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for  tactical  systems,  it  is  important  for  the  models  to  be  able  to  read  and 
extract  the  data  they  need. 

a.  CASTFOREM;  The  existing  ARTBASS  terrain  data  sets,  plus  the  new 
data  being  produced  by  WES,  will  offer  sufficient  variety  to  support  most 
CASTFOREM  study  requirements.  However,  there  will  certainly  be  special  study 
requirements  that  need  specific  terrain  locations  not  covered  by  the  DTD 
produced  in  ARTBASS  format.  To  be  able  to  quickly  respond  to  special  study 
requirements,  changes  should  be  made  to  allow  CASTFOREM  to  use  new  DTD 
formats.  Extraction  programs  to  convert  other  sources  of  DTD  to  ARTBASS 
format  would  give  CASTFOREM  access  to  new  areas  of  coverage  as  they  become 
available.  While  TRAC-WSMR  could  devel'-)  such  extraction  programs,  ESC 
recommends  ETL  perform  this  task  (in-house  or  through  contract)  since  it 
should  support  not  only  CASTFOREM,  but  the  ARTBASS  system  as  well. 

b.  VIC:  Because  VIC  has  the  greatest  potential  for  use  on  studies 
of  different  geographic  areas,  it  has  the  greatest  need  for  additional  terrain 
coverage.  TRAC-WSMR  should  give  priority  to  adapting  VIP  extraction  programs 
to  be  able  to  read  new  DTD  formats  so  that  new  coverage  is  available  for  use 
as  soon  as  it  is  produced. 

c.  FORCEM:  The  key  to  supporting  FORCEM  with  DTD  is  for  CAA  to 
develop  a  preprocessor  to  extract  DTED  and  DFAD  data  and  convert  it  to  a  form 
usable  by  FORCEM  (see  paragraph  18c).  The  existing  DTED  and  DFAD  resolution 
and  coverage  is  adequate  for  current  FORCEM  needs,  except  for  LOC  network 
descriptions.  The  proposed  new  standard  DTD  products  will  have  this  LOC  data. 
And,  the  design  of  the  FORCEM  preprocessor  should  allow  for  the  use  of  new  DTD 
sources  as  they  become  available. 

20.  Integrate  DTD  Requirements.  ETL  included  the  needs  of  the  Army 
analysis  community  in  their  1984  study,  Army  Digital  Topographic  Data  Require¬ 
ments.  These  requirements  were  validated  by  ODCSINT  and  were  formally  pre¬ 
sented  to  DMA  in  October  1984.  As  discussed  in  paragraph  3  at  the  beginning 
of  this  Annex,  the  Army  must  establish  its  most  critical  DTD  needs  (those  that 
cannot  wait  for  the  new  DMA  system)  and  develop  a  cost  effective  method  of 
producing  this  urgently  needed  data. 

a.  In  the  past,  Army  modelers  have  funded  DTD  production  by 
engaging  contractors  and  government  agencies  such  as  WES,  to  meet  model 
requirements  not  met  through  standard  DMA  terrain  products.  Such  a  case-by- 


case  approach  may  meet  the  immediate  needs  of  a  particular  model  as  used  on  a 
particular  study.  However,  this  shortsighted  approach  can  lead  to  a 
proliferation  of  data  base  formats,  unnecessary  duplication  of  coverage,  and 
needlessly  expensive  production  costs.  To  avoid  forcing  modelers  to  resort  to 
such  measures,  ETL  must  establish  standards  and  specifications  for  the  Army's 
interim  terrain  product  needs,  and  then  require  that  all  new  production 
efforts  follow  these  standards.  Fortunately,  ETL  is  organized  to  do  just 
that.  ETL's  Terrain  Analysis  Center  (TAC)  has  the  mission  of  terrain  data 
production  to  meet  Army  requirements  not  met  by  DMA,  and  ETL's  Concepts  and 
Analysis  Division  (CAD)  has  been  tasked  to  define  the  standards  and 
specifications  for  interim  DTD  products.  Unfortunately,  ETL  does  not 
presently  have  either  the  priority  or  the  resources  to  support  such  a  program. 

b.  The  study  programs  of  the  agencies  using  CASTFOREM,  VIC,  and 
FORCEM  will  determine  the  specific  DTD  coverage  required  to  support  these 
models.  It  is  beyond  the  scope  of  this  analysis  to  define  those  study 
programs.  But,  ESC  believes  VIC  will  have  the  greatest  need  for  additional 
DTD  production  --  the  available  ARTBASS  DTD  and  DTD  being  produced  by  WES  will 
give  CASTFOREM  a  variety  of  terrain  types  on  which  to  investigate  battalion- 
level  combat;  and  CAA  has  terrain  coverage  for  the  theaters  it  normally  uses 
for  FORCEM.  As  discussed  in  paragraph  16b,  the  geographic  areas  requiring  DTD 
for  new  tactical  weapons  and  C^I  systems  will  also  be  of  interest  for  use  in 
VIC-supported  studies.  To  support  both  the  fielding  vyf  the  new  Army  systems 
that  require  DTD  and  the  use  of  VIC  to  support  the  analysis  of  corps- level 
operations,  it  will  be  necessary  to  develop  DTD  for  all  areas  covered  oy  US 
corps  operation  and  contingency  plans .  To  get  a  first  approximation  of  the 
level  of  effort  involved  in  producing  this  amount  of  new  DTD,  ESC  asked  E.'L  to 
develop  a  rough  estimate  of  the  time  and  cost  required  to  produce  an  interim 
set  of  DTD  from  available  source  materials.  ETL  estimates  the  production  of 
interim  terrain  data  from  existing  hard  copy  TTADB  coverage  would  require 
about  30  staff  years,  and  would  cost  about  $2  million  (see  Figure  E-5).® 

^An  Investigation  of  Resource  Needs  for  Production  of  Digital 
TTADBs/PTADBs  in  Support  of  Army  Requirements  for  ITD ,  working  paper  (ETL, 
March  1988);  and  personal  interviews  between  Mr.  Reynolds  of  ESC  and  Mr. 
Richard  Herrmann  of  ETL  on  9  and  10  March  1988. 


DTD  RESOURCE  REQUIREMENTS  BY  REGION 


GEOGRAPHIC  REGION 

STAFF  YEARS 

DOLLARS 
(in  millions) 

EUROPE 

14.5 

1.0 

WESTERN  PACIFIC 

8.3 

0.5 

AFRICA/MIDDLE  EAST 

2.0 

0.1 

CENTRAL  AMERICA/ 
CARIBBEAN  AND  OTHER 

5.0 

0.3 

TOTAL 

29.8 

1.9 

Figure  E-5 
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c.  ESC  is  not  in  a  position  to  establish  the  Army's  priority  for 
new  DTD  production  (those  priorities  must  be  set  by  the  Deputy  Chief  of  Staff 
for  Intelligence,  in  cooperation  with  the  Deputy  Chief  of  Staff  for 
|  Operations).  Also,  ESC  believes  that  the  needs  of  new  tactical  systems  should 

be  the  primary  consideration  in  setting  the  priorities  for  new  DTD  production. 
However,  from  the  perspective  of  model  requirements  alone,  ESC  suggests 
priority  be  given  to  digitizing  the  TTADB  source  material,  since  it  has  the 
terrain  feature  information  and  data  density  most  appropriate  to  VIC.  ESC 
also  recommends  that  the  production  of  new  DTD  be  scheduled  in  the  following 
order  based  on  the  relative  priority  of  modeling  efforts  in  each  geographic 
area  (see  Figure  E-6) : 

(1)  Europe  --  Since  studies  are  most  often  designed  to  test  US 
doctrine,  tactics,  and  equipment  against  the  most  demanding  mid- intensity 
threat,  the  most  often  required  scenario  involves  modeling  a  NATO  versus 
Warsaw  Pact  conflict  in  Europe.  It  is  also  likely  that  further  arms  reduction 
negotiations  will  generate  urgent  new  requirements  to  analyze  US  combat 
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DTD  DEVELOPMENT  SCHEDULE 


GEOGRAPHIC  REGION 

FY89 

FY90 

FY91 

FY92 

EUROPE 

WESTERN  PACIFIC 

AFRICA/MIDDLE  EAST 

CENTRAL  AMERICA/ 
CARIBBEAN  &  OTHER 

m® 

Figure  E-6 
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capabilities  in  Europe.  If  FORCEM  begins  to  use  VIC  as  a  source  of  corps- 
level  battle  outcomes  (as  recommended  in  ANNEX  C) ,  DTD  will  be  needed  for  all 
NATO  corps  sectors,  not  just  the  US  corps  sectors.  Using  ETL's  estimates  of 

M  120  manhours  and  a  cost  range  of  $3,000  to  $4,200  per  map  sheet,  the  available 

TTADB  coverage  of  233  map  sheets  in  this  area  could  be  digitized  by  committing 
about  14-1/2  manyears  (27,960  manhours)  and  something  under  $1  million 
($699,000  to  $978,600) . 

(2)  Western  Pacific  --  With  US  forces  forward  deployed  and 
operating  under  a  combined  command  with  the  Republic  of  Korea  (ROK) ,  this  is 
the  next  area  where  DTD  is  most  needed  to  support  combat  models.  The  Deputy 
Undersecretary  for  Operations  Research  has  approved  the  release  of  VIC  to  the 

*  ROK/US  Combined  Forces  Command,  and  they  will  need  DTD  to  run  the  model. 
Appendix  E-l  shows  that  high  resolution  DTD  coverage  of  Korea  is  limited.  The 
most  urgent  requirement  is  for  additional  DTD  coverage  of  the  Demilitarized 
Zone  (DMZ),  but  coverage  must  eventually  be  extended  to  include  the  entire 

•  Korean  peninsula.  Using  ETL's  estimates  of  120  manhours  and  cost  range  of 
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$3,000  to  $4,200  per  map  sheet,  the  available  TTADB  coverage  of  134  map  sheets 
in  this  area  could  be  digitized  by  committing  something  over  eight  manyears 
(16,080  manhours)  and  about  $.5  million  ($402,000  to  $562,800). 

(3)  Africa/Middle  East  --  Constantly  changing  conditions  in  the 
Central  Command's  area  of  responsibility  make  it  important  for  the  modeling 
community  to  be  able  to  support  contingency  planning  in  this  volatile  area. 
Appendix  E-l  shows  that  only  a  few  countries  in  this  area  have  any  high- 
resolution  DTD  coverage,  and  that  coverage  is  limited  to  a  few  locations  in 
each  country.  Using  ETL's  estimates  of  120  manhours  and  cost  range  of  $3,000 
to  $4,200  per  map  sheet,  the  available  TTADB  coverage  of  32  map  sheets  in  this 
area  could  be  digitized  with  two  manyears  of  effort  (3,840  manhours)  and  about 
$100  thousand  ($96,000  to  $134,400). 

(4)  Central  America/Caribbean  --As  with  the  Central  Command, 
volatile  conditions  throughout  most  of  Southern  Command's  area  of  respon¬ 
sibility  make  it  important  for  the  modeling  community  to  be  able  to  support 
Southern  Command  study  needs.  Using  ETL’s  estimates  of  120  manhours  and  cost 
range  of  $3,000  to  $4,200  per  map  sheet,  the  available  TTADB  coverage  of  80 
map  sheets  in  this  area  could  be  digitized  with  five  manyears  of  effort  (9,600 
manhours)  and  between  one-quarter  and  one- third  of  $1  million  ($240,000  to 
$336,000)  . 

(5)  Other  --  There  are  certainly  other  areas  throughout  the 
world  where  contingency  missions  might  occur  (e.g.  islands  in  the  Pacific). 
But,  the  requirement  for  modeling  analysis  (particularly  VIC-level  analysis) 
is  presently  not  high  in  these  areas. 
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AirLand  Battlefield  Environment  (ALBE)  Program.  USACE  has  insti¬ 
tuted  the  ALBE  program  to  focus  upon  two  activities.  One,  to  provide  the  Army 
material  acquisition  activities  with  the  capability  of  assessing  and 
exploiting  realistic  battlefield  environmental  effects.  Second,  to  provide 
the  Army  in  the  field  with  the  capability  to  assess  and  exploit  battlefield 
environmental  effects  for  tactical  advantage.  Demonstrations  of  the  ALBE 
program  have  been  conducted  recently  on  Fort  Hood  (1986)  and  in  Korea  (1987). 
These  preliminary  demonstrations  have  used  a  computer  test  bed  system  to 
produce  tactical  decision  aids  (TDA)  to  help  the  battlefield  commander  make 
better  decisions.  The  ALBE  test  bed  system  uses  a  GIS  which  processes  DTD. 

This  GIS  uses  a  digital  data  base,  using  digitized  information  from  TTADBs  and 
other  sources. 

Areal  Feature.  An  area  completely  enclosed  by  a  delimiting  line  of 
the  feature  manuscript. 

Army  Training  Battle  Simulation  System  (ARTBASS) .  ARTBASS  can  model 
a  tactical  environment  which  can  encompass  a  surface  area  of  500  square 
kilometers  to  an  altitude  of  10  kilometers.  The  ARTBASS  is  capable  of 
modeling  a  total  of  200  units  simultaneously  during  a  simulated  exercise. 
Natural  environmental  factors  are  included  in  the  model,  for  example: 
weather,  vegetation/forestation,  ground  surface,  soil  type,  wind,  and  visibil¬ 
ity.  Each  DTD  data  base  created  for  use  on  ARTBASS  is  produced  in  a  64-bit 
fixed  field,  raster  format  with  Universal  Transverse  Mercator  (UTM)  coordi¬ 
nates  using  12.5  or  25-meter  post  spacing.  The  actual  digital  scale  is 
1:49,212.  The  ARTBASS  DTD  set  consists  of  a  UTM  digital  terrain  elevation 
data  ( DTED)  file,  a  vegetation  feature  file  containing  the  vegetation  type, 
canopy  closure,  height,  a  surface  material  file,  a  surface  drainage  file,  an 
obstacle  file,  a  transportation  file,  and  a  CCM  file  for  several  vehicles, 
both  wet  and  dry. 

Collateral  Sources.  Outside  agencies,  both  national  and  foreign, 
from  which  information  and  data  may  be  obtained. 

Critical .  Failure  of  unit  operations;  increased  probability  of 
defeat;  paramount  to  success  in  pivotal  situations. 

Data  Base  (DB) .  An  organized  set  of  evaluated  MC&G  data  stored  in 
either  graphic,  textual,  or  digital  form.  A  data  base  may  contain  one  file  of 
data  (DTED),  or  several  data  files. 

Digitize .  To  translate  an  analogue  measurement  of  data  into  a 
numerical  description  expressed  in  digits  in  a  scale  of  notation. 

Digital  Data.  Data  represented  by  digits,  perhaps  with  special 
characters  and  the  space  character. 
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Digital  Data  Base  (off-line’)  .  A  digital  data  base  maintained  in  a 
common  format  that  supports  different  user  systems.  Normally,  the  data  must 
be  transformed  before  they  can  be  used  by  a  specific  user  system. 

Digital  Data  Base  (on-line’).  A  digital  data  base  in  the  format 
needed  by  a  user  system  and  which  can  be  directly  loaded  into  the  used  system. 
This  term  is  commonly  referred  to  as  the  on-line  data  base. 

Digital  Feature  Analysis  Data  (DFAD)  .  DFAD  Level  I  consists  of 
selected  natural  and  man-made  planimetric  features,  type  classified  as  point, 
line,  or  area  features  as  function  of  their  size  and  composition.  The  data  is 
stored  in  polygon  formate  and  segregated  into  1  degree  X  1  degree  geographic 
cells.  DFAD  level  1  is  available  in  several  levels  and  editions. 

Digital  Landmass  System  (DLMS)  Data  Base.  DLMS  contains  two  digital 
data  bases,  Digital  Terrain  Elevation  Data  (DTED)  and  Digital  Feature  Analysis 
Data  (DFAD) ,  and  generally  has  an  accuracy  and  resolution  similar  to  a 
1:250,000  scale  topographic  line  map. 

Digital  Map.  A  map  expressed  and  stored  in  digital  form.  It  can 
also  be  a  representation  in  digital  form  of  discrete  points  on  the  earth's 
surface.  Also  called  a  numerical  map. 

Digital  Terrain  Data  ('DTP)  .  DTD  is  a  generic  term  used  to  describe 
any  machine  readable  file  and  or  data  base  of  topographic  date,  either  feature 
data,  elevation  data,  or  both.  DTD  is  commonly  used  to  refer  to  DLMS,  DFAD, 
DLMS  DTED,  TTD ,  STD. 

Digital  Terr' in  Elevation  Data  (DTED) .  DTED  Level  I  consists  of  a 
uniform  matrix  of  terrain  elevation  values.  The  standard  DTED  file  size  is  a 
1  degree  X  1  degree  cell.  Each  elevation  data  record  contains  1201  elevation 
values  along  a  single  meridian  with  3  arc  seconds  (latitude)  spacing.  Eleva¬ 
tion  posts  are  spaced  approximately  every  100  meters. 

Digital  Terrain  Elevation  Matrix.  Elevation  posts,  non-specific 
with  respect  to  editing  and  smoothing,  and  evenly  distributed  in  a  rectangular 
pattern. 


Digital  Terrain  Model.  A  statistical  representation  of  the  con¬ 
tinuous  surface  of  the  earth  by  a  large  number  of  selected  points  with  known 
X,Y,  Z  coordinated  in  an  arbitrary  coordinate  field. 

Digital  Topographic  Data  (DTD) .  A  generic  term  used  to  describe  the 
combination  of  both  elevation  and  feature  data  (see  also  Digital  Terrain 
Data) . 


Digital  Topographic  Support  System  fDTSS)  .  The  DTSS  will  put  the 
speed  and  flexibility  of  automation  to  work  for  the  terrain  analyst.  DTSS 
will  supply  digital  topographic  support  for  the  field  Army  in  the  1990' s.  It 
will  supply  data  for  such  tactical  users  as  the  all-source  analysis  system, 
and  the  FIREFINDER  counter  artillery  counter-mortar  radar. 
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Environment .  Consists  of  five  elements:  atmosphere,  terrain,  bat¬ 
tlefield  induced  contaminants,  background  signature,  and  illumination. 

Elevation  Post.  A  point  with  known  horizontal  and  vertical  position 
with  respect  to  some  defined  reference  system. 

Feature  Analysis.  The  process  of  locating,  examining,  and  clas¬ 
sifying  the  physical  characteristics  of  natural  and  cultural  features  on  the 
earth's  surface. 

Feature  Extraction.  The  process  of  transferring  or  encoding  feature 
analysis  data  to  a  digital  or  analog  mode. 

Feature  Type .  A  classification  of  feature  into  categories  of  point, 
linear  (line)  or  areal  features. 

Geodetic  Datum.  A  particular  association  of  an  ellipsoid  to  some 
physical  monument  on  the  earth.  It  represents  the  fixing  of  an  origin  and  the 
orientation  from  which  location  on  the  earth  is  measured. 

Grid .  A  reference  system  applied  to  maps  to  provide  a  uniform 
system  for  referencing  and  making  measurements. 

Interim  Terrain  Data  (ITD) .  ITD  will  consist  of  digitized  TTADBs 
and  PTADBs ,  together  with  DTED  Level  I.  ITD  format  and  content  will  be 
designed  to  allow  it  to  meet  interim  Army  needs  until  DMA  can  produce  TTD.  To 
the  extent  possible,  ITD  will  be  designed  to  be  a  compatible  subset  of  TTD,  so 
that  systems  using  ITD  can  easily  transition  to  TTD  when  it  becomes  available. 

Linear  Feature.  A  feature  that  is  portrayed  by  a  line  that  does  not 
represent  an  area. 

Near-Term  Requirement.  A  DTD  requirement  generated  by  an  opera¬ 
tional  system  to  be  fielded  in  the  FY  1987-FY  1993  time  period. 

Mid-Term  Requirement.  A  DTD  requirement  generated  by  an  operational 
system  to  be  fielded  in  the  FY  1993-FY  2002  time  period. 

Far-Term  Requirement.  A  DTD  requirement  generated  by  an  operational 
system  to  be  fielded  in  the  FY  2002-FY  2011  time  period. 

Operational  System.  A  system  that  has  passed  the  first  unit 
equipped  state  of  development  and  is  either  fielded  or  in  the  process  of  being 
fielded. 


Planning  Terrain  Analysis  Data  Base  (PTADB) .  The  PTADB  is  a  set  of 
hard  copy  overlays  keyed  to  a  1:250,000  scale  topographic  line  map.  The  PTADB 
is  limited  to  a  few  key  natural  and  man-made  features  used  to  satisfy  military 
planning  requirements.  These  features  include:  surface  configuration 
(slope),  vegetation,  surface  materials,  surface  drainage,  transportation, 
obstacles,  and  water  resources. 
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Point  Feature.  An  object  whose  location  can  be  described  by  a 
single  set  of  coordinates. 

Resolution .  A  measure  of  the  smallest  possible  difference  in  value 
or  position.  In  a  computer  system,  this  may  be  numerical  resolution  or 
physical  resolution  of  the  hardware;  e.g.,  plotter  step  size  or  digitizer 
resolution . 


Raster .  A  regular,  two  dimensional  arrangement  of  physical  or  con¬ 
ceptual  elements;  e.g.,  addressable  points.  Sometimes  synonymous  with  grid, 
and  also  matrix. 

Special  Terrain  Data  ('STD').  STD  contains  elevation  and  feature  data 
sets  similar  to  TTD.  This  data  base,  however,  is  much  more  detailed  and 
accurate  than  TTD,  with  resolution  requirements  relatively  equivalent  to  a 
1:12,500  scale  topographic  line  map  and  associated  terrain  analysis  products. 
While  STD  is  a  stated  Army  requirement,  DMA  has  said  it  will  not  address  this 
requirement  until  after  the  Mark  90  system  is  operational  and  TTD  requirements 
are  being  met. 

Tactical  Terrain  Analysis  Data  Base  (TTADB) .  The  TTADB  is  a  set  of 
hard  copy  topical  overlays  keyed  to  a  1:50,000  scale  topographic  line  map. 

This  data  base  is  limited  to  those  natural  and  man-made  features  of  tactical 
military  significance.  These  features  consist  of  surface  configuration 
(slope),  vegetation,  surface  materials,  surface  drainage,  transportation,  and 
obstacles . 


Tactical  Terrain  Data  (TTD'i  .  TTD  is  a  data  set  similar  in  content, 
accuracy,  and  resolution  to  a  Class  B,  1:50,000  scale  topographic  map/terrain 
analysis  study.  TTD  will  contain  unsynthesized  and  unsymbolized  feature  and 
attribute  data,  plus  elevation  data.  Feature  and  attribute  data  will  include 
information  about  the  size,  shape,  location,  and  height  of  extracted  features. 
The  elevation  matrix  will  contain  elevation  posts  every  30  meters  (1  arc 
second)  referenced  to  the  World  Geodetic  system.  TTD  is  considered  the  Army's 
operational  support  data  base  and  will  meet  most  user  requirements  when  it 
becomes  available.  However,  DMA  will  not  begin  producing  TTD  until  the  Mark 
90  system  becomes  operational. 

Terrain  Analysis  Work  Station  (TAWS).  TAWS  is  a  prototype  of  the 
DTSS.  TAWS  includes  four  major  components:  data  base  development,  terrain 
analysis  and  product  generation,  intervisibility  analysis  and  product  genera¬ 
tion,  and  environmental  effects  software.  The  data  base  development  is  a 
terrain  analysis  data  base  which  typically  includes  factor  overlays  covering 
soil,  drainage,  transportation,  vegetation,  slope  and  obstacles. 

Terrain  Modeling.  The  mathematical  modeling  of  the  physical  shape 
of  a  portion  of  the  earth's  surface  (terrain)  by  fitting  functions  to  the 
elevation  data. 

Transformation  program.  A  computer  program  used  to  change  digital 
data  from  one  format  to  another  (e.g.,  from  planar  to  DMA  standard). 


Vital .  Jeopardizes  the  existence  of  the  division;  high  loss  of 
life,  and  early  defeat  of  the  unit. 

VIC  Terrain  Classification  Algorithm.  VIC  classifies  relief  into 
three  classes:  mountains,  hills,  and  flat  areas.  This  is  accomplished  by  a 
three-step  process.  First  DTED  is  read,  reduced,  and  synthesized  into  a  cell 
(4  km  X  4  km)  value.  Second,  cell  values  are  then  referenced  to  a  terrain 
look-up  table  based  on  the  Natick  Landform  classification  system.  This  system 
describes  surface  roughness  within  a  landform  compartment  by  specifying  three 
characteristics:  maximum  local  relief,  modal  local  relief,  and  average  number 

of  positive  features  per  unit  distance.  A  code  is  assigned  based  on  these 
characteristics.  Finally,  these  codes  are  then  reduced  to  a  plains,  hills,  or 
mountain  rating. 

WES-Mobilitv  Terrain  Data  Bases.  Development  of  mobility- terrain 
data  bases  has  been  supported  in  part  by  funds  from  TRAC  to  provide  realistic 
mobility  input  to  the  CARMONETTE  Model  for  wargaming.  The  data  bases  are 
generally  referenced  to  groups  of  1:50,000  topographic  line  maps.  The  data 
are  at  100  meter  resolution  and  represent  those  terrain  factors  and  seasonal 
conditions  that  influence  vehicle  performance.  Five  major  DTD  features  have 
been  developed  for  CARMONETTE/CASTFOREM :  road  code,  tree  heights,  CCM  code, 
elevation,  and  vehicle  speeds.  These  five  features  are  derived  from  the 
digital  terrain  data  base  which  is  composed  of  many  factors,  a  few  of  which 
are  soil  types,  slope,  urban  code,  surface  roughness,  vegetation  spacing,  road 
codes,  bridge  codes,  tunnel  codes,  river  and  stream  widths,  and  water-gap  bank 
conditions . 
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1. 

I .  INTRODUCTION 

Purpose.  This  annex  identifies  those  engineer  tasks  whirh 

should  be 

represented  in  combat  simulations  at  each  level  of  the  AMIP  hierarchy. 

2.  Scope .  This  analysis  is  based  on: 

a.  Consolidated,  ranked  lists  of  engineer  tasks  used  by  ESC  to 
support  a  series  of  studies  conducted  between  1980  and  1987.  These  ranked 
lists  of  engineer  tasks  represent  the  opinions  of  field  commanders  and  their 


staffs  from  theaters  throughout  the  world  about  the  relative  importance  of 
individual  engineer  tasks  to  success  on  the  battlefield. 

b.  Person-to-person  interviews  conducted  with  members  of  the 
modeling  and  analysis  community  about  how  existing  models  play  engineers. 

c.  An  "expert  judgement"  survey  prepared  and  distributed  by  ESC 
which  asked  modelers,  engineer  officers,  and  field  commanders  to  rank  engineer 
tasks  under  multiple  judgement  criteria. 

3.  Limits .  In  accepting  the  assignment  to  formulate  a  comprehensive 
plan  for  improving  engineer  play  in  combat  simulations,  ESC  wished  to  avoid 
recommending  a  series  of  haphazard,  expedient  fixes  to  the  way  engineers  are 
now  represented  in  existing  models.  Therefore,  this  analysis  began  by  framing 
an  overall  picture  of  which  engineer  tasks  are  most  important  to  the  success 
of  the  combined  arms  team  on  the  battlefield.  By  analyzing  the  relative 
importance  of  engineer  tasks  in  a  general  philosophical  way  --  without  regard 
to  the  capabilities  or  weaknesses  of  specific  models  --  it  will  be  possible  to 
logically  and  consistently  describe  the  desired  level  of  engineer  play  in 
specific  models,  and  then  to  propose  appropriate  modifications  to  those 
models . 

4.  Background.  ESC  has  conducted  engineer  assessments  that  quantify  the 
requirements  for  engineer  support  to  combat  forces  under  approved  operations 
plans  (OPLANS)  for  the  Combined  Forces  Command,  Korea;  the  US  Army  Europe;  the 
Third  US  Army;  the  III,  V,  and  VII  US  Corps;  the  9th  Infantry  Division;  and 
the  Light  Infantry  Division.  Each  assessment  was  built  around  a  list  of 
engineer  tasks,  sorted  into  priority  order  by  a  Study  Advisory  Group  (SAG) 
comprising  representatives  of  the  sponsors'  general  staff  and  major 
subordinate  commands.  These  task  lists  are  key  to  this  analysis,  since  they 
represent  field  commanders'  opinions  of  the  type  and  order  of  engineer  tasks 
that  must  be  completed  to  accomplish  their  OPLAN  missions.  In  addition,  the 
technique  of  breaking  engineer  tasks  into  categories  and  sorting  the 
categories  in  priority  order  is  well  suited  to  deciding  what  engineer  tasks 
are  needed  in  the  simulation  models  established  at  each  level  of  the  AMIP 
hierarchy . 

5.  Method .  This  analysis  began  by  grouping  engineer  tasks  by  category, 
then  ranking  the  categories  in  terms  of  the  battlefield  priority  assigned  them 
by  field  commanders.  However,  instead  of  having  a  SAG  work  out  an  approved 
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list  of  engineer  tasks  based  on  specific  OPLAN  missions,  ESC  developed  an 
"expert  judgement  survey"  to  get  a  balanced  view  of  the  engineer  role  on  the 
battlefield  under  a  wide  range  of  combat  conditions.  In  other  words,  the 
survey  consolidated  the  need  for  different  types  and  levels  of  engineer  model 
play,  as  expressed  by  experts  from  many  different  disciplines  and  with 
difieLent  levels  of  modeling  experience. 

a.  This  analysis  also  grouped  engineer  tasks  into  categories  using 
criteria  different  from  the  criteria  used  to  develop  task  lists  for  the 
engineer  assessments.  For  the  assessments,  tasks  were  broken  into  categories 
based  on  criteria  meaningful  to  tactical  planners.  For  example,  to  a  com¬ 
mander  planning  a  defense,  obstacles  on  the  primary  avenue  of  approach  would 
be  more  important  than  obstacles  on  a  secondary  avenue  of  approach;  therefore, 
primary- avenue  obstacles  are  put  in  a  separate  category  from  secondary- avenue 
obstacles.  When  choosing  tasks  to  represent  in  a  simulation  model,  however, 
it  does  not  matter  where  the  tasks  occur:  generating  and  locating  tasks 
within  the  model  is  a  separate  problem  which  is  tackled  only  ^after  it  is 
decided  which  tasks  the  model  will  represent. 

b.  The  Expert  Judgement  Survey  divided  engineer  tasks  into  the  16 
categories  listed  in  Figure  F-l.  These  categories  are  based  on  the  way 
engineer  functions  will  interact  with  other  combat  functions  in  models  at 
different  levels,  from  high- resolution  models  (battalion/company  level)  to 
low-resolution  models  (theater/army  level) . 

c.  Figure  F-l  does  not  cover  every  function  engineers  perform  on  the 
battlefield,  although  each  category  covers  a  wide  variety  of  engineer 
activities.  A  listing  of  the  kinds  of  tasks  included  in  each  category  is 
given  as  Appendix  F-l.  However,  even  if  all  the  tasks  implied  by  categories  1 
through  15  are  considered  candidates  for  modeling,  many  engineer  functions 
will  still  remain  unaccounted  for.  This  is  intentional  --  all  models  are 
abstractions  of  reality.  In  creating  any  model,  some  things  must  be  left  out 
so  the  model -maker  can  focus  on  the  functions  most  important  to  the  intended 
uses  of  the  model.  It  is  not  in  the  best  interests  of  either  the  analytic 
community  or  the  engineers  to  insist  on  incorporating  all  engineer  functions 
into  every  model  which  simulates  combined  arms  combat.  Even  if  one  ignores 
both  the  lengthy  development  requirements  for  such  an  intricate  model  and  the 
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ENGINEER  TASK  CATEGORIES  DERIVED  FROM  PAST  ESC  STUDIES 


1.  Install  linear  obstacles  (minefields,  tank  ditches...) 

2.  Install  point  obstacles  (road  craters,  bridge  demolition...) 

3.  Prepare  fighting  positions  for  direct  fire  systems  (tanks,  TOWS...), 

4.  Prepare  positions  for  indirect  fire  &  other  systems  (artillery, 

ADA ,  CP _ ) 

5.  Breach  obstacles  in  the  assault  (breach  minefields,  span  short  gaps...) 

6.  Improve  assault  breaches  for  follow-on  forces  (clear  minefields, 

widen  lanes . . . ) 

7.  Conduct  river  crossing  operation  in  the  assault  (bank  clearing, 

rafting,  assault  bridging...) 

8.  Improve  river  crossing  site  for  follow-on  forces  (fixed  bridging, 

float  bridging. . . ) 

9.  Maintain  main  supply  routes  (fill  craters,  build  up  worn  shoulders...) 

10.  Pioneer  trail  preparation  &  maintenance  (route  clearing,  soil 

stabilization. . . ) 

11.  Forward  airlanding  facility  preparation  &  maintenance  (air  strip 

clearing,  soil  stabilization...) 

12.  Site  preparation  &  maintenance  for  combat  support  &  combat  service 

support  units  (access  road,  site  clearing...) 

13.  Rear  area  facility  rehabilitation  &  maintenance  (building 

conversion,  damage  repair...) 

14.  Airfield  damage  repair  (crater  repair,  rubble  clearing...) 

15.  Port  &  waterfront  facilities  construction  &  repair  (pier  repair, 

storage  facility  rehabilitation...) 

16.  Other  (While  there  are  many  other  engineer  tasks,  respondents  were 

asked  to  add  tasks  only  if  the  tasks  were  vital  to  model  integrity.) 


Figure  F-l 
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challenge  of  assembling  valid  input  data,  the  investments  in  time  and  effort 
to  run  such  a  model  would  make  it  impractical  to  use. 

d.  The  key  to  model  building  is  to  represent  those  functions  that 
have  the  greatest  impact  en  the  phenomenon  being  modeled.  In  defining  the 
engineer  modeling  requirements  for  the  AMIP,  ESC  tried  to  exclude  engineer 
tasks  that,  though  important,  only  indirectly  affect  the  outcome  of  combat 
simulations.  To  ensure  no  critical  engineer  functions  were  overlooked,  the 
Expert  Judgement  Survey  included  category  16,  so  the  experts  surveyed  couiu 
add  engineer  tasks  they  believed  must  be  modeled. 


II.  DESCRIPTION  OF  THE  EXPERT  JUDGEMENT  SURVEY 


6.  Survey  Questionnaire.  Appendix  F-2  to  this  annex  is  a  copy  of  the 
questionnaire  ESC  used  to  define  and  rank  the  importance  of  engineer  tasks. 

At  the  heart  of  the  survey  are  the  16  engineer  task  categories  listed  in 
Figure  F-l .  Because  the  issue  of  what  engineer  tasks  need  to  be  represented 
in  combat  simulations  has  many  different  aspects,  the  survey  asks  respondents 
to  rank  the  importance  of  each  task  category  in  terms  of  several  different 
judgement  criteria.  The  survey  also  asks  respondents  to  assign  weights  to  the 
judgement  criteria  based  on  how  much  influence  they  think  each  criterion 
should  have  in  determining  each  task's  final  rank.  This  analysis  approach 
provides  an  organized  way  of  making  decisions  about  which  of  many  different 
alternatives  is  the  best,  especially  when  the  alternatives  have  different 
values  under  different  criteria. 

a.  The  decision  process  involved  in  buying  a  car  is  the  classic 
example  of  how  this  technique  is  best  applied.  The  buyer  ranks  each  car  being 
considered  against  different  judgement  criteria  --  cost,  reliability,  gas 
mileage.  The  buyer  then  weights  those  judgement  criteria  based  on  the  impor¬ 
tance  of  each  to  the  overall  decision.  The  rank  each  car  is  assigned  under 
each  judgement  criterion  is  multiplied  by  the  weight  assigned  the  criterion. 
The  weighted  criterion  values  are  added  to  produce  an  overall  score  for  each 
car.  The  buyer  then  selects  the  car  which  earns  the  highest  score. 

b.  The  strength  of  this  technique  is  its  ability  to  handle  subjec¬ 
tive  opinions  as  well  as  quantitative  data.  In  the  car-buying  example,  the 
purchaser  could  make  "style"  one  c?  the  judgement  criterion  and  score  each  car 
on  its  style.  Of  course,  different  people  will  have  different  opinions  about 
what  is  "good"  or  "bad"  style,  and  so  different  people  will  rank  the  same  cars 
differently.  But  as  long  as  all  purchasers  use  their  own  ranking  system,  the 
technique  will  work  for  each  of  them. 

c.  Ensuring  logical  consistency  becomes  more  complicated  when  the 
technique  is  used  on  a  problem  that  involves  organizational  rather  than 
personal  decisions.  In  such  cases,  no  one  person  has  a  complete  perspective, 
and  so  no  one  person  can  accurately  rank  all  alternatives.  Clearly,  in  the 
case  of  deciding  what  engineer  play  is  needed  in  Army  models,  no  one  person 
can  claim  to  be  the  authority.  That  is  why  the  survey  used  in  this  analysis 
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collected  a  wide  variety  of  opinions  from  experts  in  Army  modeling  and  analy¬ 
sis,  engineer  functions  and  doctrine,  and  operational  planning. 

7.  Survey  Respondents .  To  gain  different  perspectives  on  the  issue  of 
engineer  play  in  combat  simulations ,  the  Expert  Judgement  Survey  was  sent  to 
people  working  in  the  organizations  listed  in  Figure  F-2.  ESC  also 
transcribed  the  ranked  engineer  tasks  lists  developed  for  its  eight  engineer 
assessments  into  the  survey  format.  This  was  not  a  straightforward  conver¬ 
sion,  however.  The  task  list  developed  by  each  SAG  for  each  engineer  assess¬ 
ment  is  unique,  since  it  is  tailored  to  a  specific  OPLAN.  The  task  categories 
in  the  Expert  Judgement  Survey  are  more  general  than  those  used  in  the 
engineer  assessments.  Therefore,  the  tasks  included  in  each  assessment  list 
had  to  be  reaggregated  under  the  survey  categories.  For  example,  the  Expert 
Judgement  Survey  aggregated  primary,  alternate,  and  supplementary  fighting 
positions  for  direct-fire  weapons  under  a  single  category:  prepare  fighting 
positions  for  direct-fire  systems. 

ORGANIZATIONS  SURVEYED 


Department  of  the  Army 
Concepts  Analysis  Agency 

US  Army  Training  and  Doctrine  Command  (TRADOC) 

US  Army  Engineer  School  (USAES) 

US  Army  TRADOC  Analysis  Command,  White  Sands  Missile 
Range  (TRAC-WSMR) 

US  Army  TRADOC  Analysis  Command,  Fort  Leavenworth 
(TRAC-FLVN) 

US  Army  Corps  of  Engineers  (USACE) 

Waterways  Experiment  Station  (WES) 

Engineer  Studies  Center  (ESC) 


Figure  F-2 


III.  ANALYSIS  OF  SURVEY  RESULTS 


8.  Limits  of  Survey  Results.  The  Expert  Judgement  Survey  was  designed 
to  be  very  broad  and  general  in  scope.  The  judgement  criteria,  task  cate¬ 
gories,  and  rating  scales  were  all  selected  to  give  respondents  as  much 
flexibility  as  possible  in  the  way  they  chose  to  fill  out  the  form. 

a.  Some  respondents  commented  that  since  they  were  given  so  much 
latitude  to  interpret  the  survey  in  their  own  way,  the  final  results  must 
necessarily  be  subject  to  a  great  deal  of  statistical  uncertainty.  This 
criticism  is  absolutely  true,  but  the  subjective  nature  of  the  problem  made  it 
important  to  maintain  a  broad  perspective,  rather  than  risk  missing  important 
aspects  of  the  problem  by  leading  respondents  to  think  in  narrower,  more 
limited  terms. 

b.  Since  the  survey  was  general  in  scope,  the  results  must  be  used 
only  to  gain  insights  into  the  categories  of  engineer  tasks  which  must  be 
considered  in  combat  simulations.  The  ranks  assigned  engineer  tasks  as  a 
result  of  this  survey  are  the  foundation  from  which  ESC  developed  specific 
recommendations  on  how  to  modify  existing  simulation  models  to  better  repre¬ 
sent  engineer  play  (see  Annexes  A  through  D) .  However,  the  task  priorities 
suggested  by  this  survey  were  not  the  only  basis  for  determining  how  the 
existing  models  should  be  modified.  Besides  the  survey  rankings,  the  analyst 
who  examined  each  model  considered  the  specific  scope  of  that  model,  how  it 
operates,  who  uses  it,  what  it  is  used  for,  and  how  engineers  are  now  played 
by  the  model. 

9 .  Judgement  Criteria. 

a.  High-,  medium-,  vs  low-resolution.  Most  respondents  considered 
high-,  medium-,  and  low-resolution  models  of  equal  importance  in  the  Army 
hierarchy  of  models.  Those  respondents  that  assigned  different  weights,  felt 
the  high-  and  medium-resolution  models  were  more  important.  The  combined 
respondent  scores  give  the  high-resolution  models  a  weight  of  40  percent,  the 
medium- resolution  models  a  weight  of  32  percent,  and  the  low- resolution  models 
a  weight  of  28  percent.  These  statistics  indicate  a  strong  consensus  that 
engineer  play  is  important  at  all  three  levels. 

b.  Defense  vs  offense.  Many  respondents  gave  equal  weight  to  the 
importance  of  playing  engineer  support  to  the  defense  and  to  the  offense. 
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This  is  not  unreasonable,  since  combat  models  must  play  both  sides  of  a 
conflict.  Therefore,  defense  and  offense  must  both  be  adequately  represented. 
However,  since  the  focus  of  model  analysis  is  usually  on  changes  that  can  be 
made  to  improve  the  position  of  the  friendly  forces,  and  since  more  data  are 
available  on  friendly  forces,  models  typically  represent  friendly  forces  in 
greater  detail  than  enemy  forces.  If  defense  and  offense  are  to  be  emphasized 
differently  by  a  model,  the  most  likely  posture  of  the  friendly  forces  should 
be  given  the  greater  weight.  Those  respondents  that  assigned  different 
weights  gave  more  importance  to  engineer  play  in  the  defense.  The  combined 
scores  of  all  respondents  give  defense  a  61-percent  weight  and  offense  a  39- 
percent  weight.  These  statistics  are  not  surprising,  since  most  model  scenar¬ 
ios  put  US  forces  in  the  defense. 

c.  Manpower  vs  equipment.  Only  one  respondent  considered  engineer 
manpower  more  important  than  engineer  equipment  on  the  battlefield.  All  other 
respondents  assigned  manpower  and  equipment  equal  weights,  or  gave  equipment  a 
greater  weight.  The  combined  scores  of  all  respondents  give  engineer  equip¬ 
ment  a  59 -percent  weight  and  engineer  manpower  a  41 -percent  weight.  These 
statistics  agree  with  current  modeling  practice,  since  even  the  high-resolu¬ 
tion  models  track  equipment  (weapon  systems)  much  better  than  people. 

d.  Ease  of  programming  vs  data  acquisition.  Many  respondents  said 
that  the  effort  required  to  program  an  engineer  task  into  a  model  --  or  to 
collect  the  data  input  necessary  to  play  the  task  --  should  not  be  considered 
in  deciding  what  tasks  to  model.  A  typical  comment  was  that  the  selection  of 
tasks  to  model  "...should  be  based  on  battlefield  requirements  and  priorities, 
not  modeling  or  data  considerations."  Of  the  respondents  that  did  give 
weights  to  these  criteria,  about  half  weighted  them  equally.  The  rest 
weighted  ease  of  data  acquisition  as  more  important  than  ease  of  programming. 
The  combined  scores  of  all  respondents  who  assigned  weights  to  these  criteria 
give  ease  of  data  acquisition  a  59-percent  weight  and  ease  of  programming  a 
41-percent  weight.  These  statistics  show  that  respondents  believe  data 
acquisition  is  more  of  a  problem  than  programming.  However,  it  also  shows  a 
strong  feeling  that  model  modifications  should  be  driven  by  the  criteria  that 
are  important  to  the  use  of  the  model,  not  by  the  criteria  that  are  important 
to  the  development  of  the  model. 
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e.  Level  of  simulation,  posture,  and  resources  vs  ease  of  modeling. 
When  asked  to  compare  the  relative  importance  of  the  four  criteria  --  level  of 
simulation,  combat  posture,  engineer  resources,  and  ease  of  modeling  --  ease 
of  modeling  was  given  a  low  weight  by  all  respondents  (zero  in  many  cases) . 

The  remaining  criteria  were  all  given  roughly  equal  weights.  The  combined 
scores  of  all  respondents  give  level  of  simulation  a  weight  of  34  percent, 
combat  posture  a  weight  of  30  percent,  engineer  resources  a  weight  of  29 
percent,  and  ease  of  modeling  a  weight  of  7  percent.  These  statistics 
reinforce  the  opinion  that  important  model  modifications  should  not  be  avoided 
just  because  a  particular  function  is  hard  to  model. 

10.  Task  Rankings .  Each  respondent's  overall  ranking  of  ♦‘he  engineer 
tasks  included  in  the  Expert  Judgement  Survey  was  computed  by  multiplying  each 
task  by  the  criteria  weight  assigned  by  that  respondent.  This  was  done  to 
accurately  preserve  each  respondent's  opinion.  These  individual  task  rankings 
were  combined  to  pro  ’uce  the  overall  rankings  listed  in  Figures  F-3  through 
F-5 . 

a.  In  its  engineer  assessments,  ESC  has  found  it  useful  to  collect 
ranked  tasks  into  four  groups  --  vital  tasks,  critical  tasks,  essential  tasks, 
and  necessary  tasks.  These  groups  further  order  engineer  effort  in  opera¬ 
tional  planning.  These  same  groups  can  be  appropriately  used  to  order  tasks 
based  on  their  importance  in  combat  simulations. 

b.  Respondents  were  not  asked  to  categorize  tasks  as  vital,  criti¬ 
cal,  essential,  or  necessary.  That  aggregation  was  done  by  ESC  after  the 
survey's  overall  ranks  were  computed.  However,  these  groups  do  seem  to  fit 
the  natural  clustering  in  the  task  lists.  The  clustering  is  most  distinct  in 
the  high-resolution  ranking  (Figure  F-3),  where  only  2.7  percentage  points 
separate  the  lowest  vital  task  from  the  highest  critical  task.  The  clustering 
is  less  pronounced  in  the  medium- resolution  ranking  (Figure  F-4) ,  but  is  still 
clear  enough  to  make  the  groupings  unambiguous.  The  low-resolution  ranking 
(Figure  F-5)  is  much  more  uniformly  distributed,  and  grouping  tasks  becomes 
somewhat  arbitrary  (particularly  deciding  the  exact  dividing  line  between 
vital  tasks  and  critical  tasks) .  ESC  tested  the  consistency  of  these  groups 
by  comparing  the  task  rankings  of  the  analytic  community  (CAA,  TRAC,  and  USACE 
respondents),  the  engineer  doctrine  experts  (USAES),  and  the  0 PLAN  experts 
(SAGs).  For  high- resolution  models,  both  the  analytic  community  and  the  USAES 
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HIGH-RESOLUTION  MODELS  --  OVERALL  TASK  RANKING 

Priority 

Task  Categories  Sorted  Ranking 

_ in  Priority  Order _ (%) 

Vital  Task  Group 

Prepare  fighting  positions  for  direct-fire  systems  12.1 

Install  linear  obstacles  11.1 

Breach  obstacles  in  the  assault  10.8 

Install  point  obstacles  10.0 

Prepare  positions  for  indirect- fire  &  other  systems  9.1 

Conduct  river  crossing  operations  in  the  assault  8.4 

Critical  Task  Group 

Improve  assault  breaches  for  follow-on  forces  5.7 

Maintain  main  supply  routes  5.7 

Pioneer  trail  preparation  &  maintenance  5 . 3 

Improve  river  crossing  sites  for  follow-on  forces  4.9 

Forward  airlanding  facility  preparation  &  maintenance  4.7 

Site  preparation  &  maintenance  for  CS  &  CSS  units  4.5 

Essential  Task  Group 

Rear  area  facility  rehabilitation  &  maintenance  2.5 

Airfield  damage  repair  2.2 

Necessary  Task  Group 

Other  (engineer  raids)  1.6 

Port  &  waterfront  facilities  construction  &  repair  1.0 


Figure  F-3 
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MEDIUM-RESOLUTION  MODELS 


OVERALL  TASK  RANKING 


Priority 

Task  Categories  Sorted  Ranking 

in  Priority  Order _ (%) 


Vital  Task  Group 

Install  linear  obstacles  10.7 

Prepare  fighting  positions  for  direct-fire  systems  10.7 

Prepare  positions  for  indirect  fire  &  other  systems  8.8 

Breach  obstacles  in  the  assault  8.5 

Conduct  river  crossing  operations  in  the  assault  7.9 

Install  point  obstacles  7.7 

Critical  Task  Group 

Forward  airlanding  facility  preparation  &  maintenance  6.7 

Maintain  main  supply  routes  6.5 

Pioneer  trail  preparation  &  maintenance  5.6 

Airfield  damage  repair  5.6 

Improve  river  crossing  sites  for  follow-on  forces  5.4 

Improve  assault  breaches  for  follow-on  forces  5.0 

Site  preparation  6t  maintenance  for  CS  &  CSS  units  4.8 

Essential  Task  Group 

Rear  area  facility  rehabilitation  &  maintenance  3.1 

Necessary  Task  Group 

Port  &  waterfront  facilities  construction  &  repair  1.5 

Other  (engineer  raids  &  nuclear  rubble  removal)  1.1 


Figure  F-4 
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LOW-RESOLUTION  MODELS  --  OVERALL  TASK  RANKING 


Task  Categories  Sorted 
in  Priority  Order 


Priority 
Ranking 
_ (%) 


Vital  Task  Group 


Install  linear  obstacles 

Prepare  fighting  positions  for  direct- fire  systems 
Airfield  damage  repair 
Maintain  main  supply  routes 

Prepare  positions  for  indirect- fire  &  other  systems 
Port  &  waterfront  facilities  construction  &  repair 
Site  preparation  &  maintenance  for  CS  &  CSS  units 
Breach  obstacles  in  the  assault 
Rear  area  facility  rehabilitation  &  maintenance 

Critical  Task  Group 


Forward  airlanding  facility  preparation  &  maintenance 
Conduct  river  crossing  operations  in  the  assault 
Install  point  obstacles 
Pioneer  trail  preparation  &  maintenance 

Essential  Task  Group 

Improve  river  crossing  sites  for  follow-on  forces 
Improve  assault  breaches  for  follow-on  forces 


8.9 

8.8 

8.1 

7.8 

6.9 
6.8 
6.7 
6.5 
6.4 


6.1 

5.8 

5.6 

5.5 


4.7 

4.0 


Necessary  Task  Group 

Other  (engineer  raids) 


1.2 


Figure  F-5 
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rank  the  same  six  tasks  at  the  top.  These  six  tasks  match  the  task  categories 
grouped  under  the  vital  heading  by  ESC  in  the  overall  survey  ranking.  The 
SAGs '  ranking  has  four  of  the  same  tasks  at  the  top  of  their  list.  However, 
in  the  SAG  list,  "maintain  main  supply  routes"  and  "prepare  and  maintain 
pioneer  trails"  moved  up  from  the  critical  task  group  to  the  vital  task  group. 
This  shows  the  importance  field  commanders  place  on  keeping  the  lines  of 
communication  open. 

c.  For  medium-resolution  models,  the  analytic  community  and  the 
USAES  again  ranked  the  same  six  tasks  at  the  top.  These  tasks  again  matched 
the  vital  task  group  in  the  overall  survey  ranking.  The  SAGs  ranked  five  of 
the  same  tasks  at  the  top  of  their  list.  The  task,  "prepare  and  maintain 
forward  airlanding  facilities,"  moved  up  from  the  critical  task  group  to  the 
vital  task  group  in  the  SAG's  list.  Again,  this  reflects  the  field  com¬ 
manders'  concerns  with  the  lines  of  communication  needed  to  sustain  their 
forces . 

d.  For  low-resolution  models,  the  analytic  community  gives  top 
ratings  to  the  same  nine  tasks  grouped  by  ESC  under  the  vital  task  group.  The 
USAES  summary  task  rankings  match  except  for  one  task  category  --  install 
point  obstacles.  The  SAGs'  have  five  task  categories  that  match.  The  four 
that  move  up  o«  the  list  are  "preparation  and  maintenance,  forward  airlanding 
facilities,"  "preparation  and  maintenance,  pioneer  trails,"  "install  point 
obstacles,"  and  "conduct  river  crossing  operations  in  the  assault."  These 
differences  appear  to  reflect  USAES  and  SAG  interest  in  forward  area  opera¬ 
tions  even  in  low-resolution  models. 

e.  ESC  found  similar  results  in  comparing  the  critical,  essential, 
and  necessary  task  groups  to  the  ranks  assigned  by  the  analytic  community, 
USAES,  and  the  SAGs.  Except  for  the  respondents'  identities  (which  are  pro¬ 
tected  by  the  Privacy  Act  of  1974),  all  of  the  survey  data  are  on  file  at  ESC. 
They  are  available  to  anyone  interested  in  doing  a  more  detailed  examination 
of  the  results. 

11.  "Other"  Engineer  Tasks.  The  Expert  Judgement  Survey  allowed 
respondents  to  add  tasks  under  category  16,  "Other."  Only  two  "other"  tasks 
were  identified.  Because  of  their  relatively  specialized  nature,  they  placed 
low  in  the  overall  ranking.  One  of  the  "other"  tasks  proposed  by  a  survey 
respondent  was  "nuclear  rubble  removal."  This  task  could  be  considered  as  an 
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extreme  special  case  of  main  supply  route  maintenance  and  damage  repair,  but 
an  accurate  representation  would  probably  require  extra  model  modifications. 
The  other  additional  task,  "engineer  raid,"  was  proposed  by  SAGs  during 
several  of  ESC's  engineer  assessments.  The  SAGs  for  these  assessments  planned 
engineer  supported  raids  as  denial  missions  forward  of  the  FEBA.  The  effect 
of  such  raids  could  probably  be  represented  in  some  models  using  other  combat 
elements,  but  the  model  would  have  to  be  modified  to  reflect  the  unique 
engineer  capabilities  needed  to  execute  such  missions.  Although  these  tasks 
did  not  place  high  enough  in  the  rankings  to  rate  inclusion  in  Army  models  at 
this  time,  they  do  represent  unique  engineer  contributions  to  the  combined 
arms  team  that  should  be  analyzed. 
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IV.  CONCLUSIONS  AND  RECOMMENDATIONS 


12.  Conclusions .  This  survey  was  successful  in  gathering  and  consoli¬ 
dating  a  broad  spectrum  of  opinions  on  the  relative  importance  of  engineer 
tasks  in  combat  simulations.  However,  the  summary  results  cannot  be  inter¬ 
preted  as  representing  a  consensus.  Each  respondent's  answers  reflect  only 
his  or  her  own  area  of  expertise.  No  attempt  was  made  to  get  respondents  to 
agree.  Thus,  the  survey  results  provide  a  general  outline  of  the  kinds  of 
engineer  tasks  that  should  be  represented  in  combat  simulations,  without 
regard  to  the  practical  implications  of  trying  to  incorporate  those  tasks  in 
specific  models. 

a.  Some  important  engineer  tasks  are  beyond  the  scope  of  high- 
resolution  models.  The  general  list  of  16  task  categories  used  in  the  survey 
includes  tasks  that  are  beyond  the  scope  of  current  high- resolution  models. 

The  duration  of  the  engagement  and  the  size  of  the  battlefield  played  in  high- 
resolution  models  make  it  impractical  to  represent  such  tasks  as  rear  area 
facility  rehabilitation  and  airfield  damage  repair.  The  fact  that  these  tasks 
scored  low  in  the  priority  ranking  gives  credibility  to  the  survey  ranking 
process . 

b.  Most  engineer  tasks  fall  within  the  scope  of  medium- resolution 
models.  The  scope  of  current  medium-resolution  models  comes  closest  to 
covering  all  of  the  categories  of  engineer  tasks  identified  by  ESC's  Expert 
Judgement  Survey.  A  strong  program  to  improve  engineer  play  in  models  at  this 
level  would  have  the  greatest  potential  payoff.  However,  models  at  this  level 
lack  the  resolution  to  analyze  changes  in  individual  pieces  of  equipment  and 
small  unit  tactics.  The  respondents  to  the  survey  rated  improvements  to 
engineer  play  in  high-resolution  models  as  slightly  more  desirable  than 
improvements  in  medium- resolution  models  (high- resolution  —  40  percent: 
medium- resolution  =  32  percent) . 

c.  Some  engineer  tasks  cannot  be  explicitly  represented  by  low- 
resolution  models.  The  design  of  current  low- resolution  models  is  such  that 
the  general  list  of  16  task  categories  used  in  the  survey  includes  tasks  that 
cannot  be  explicitly  represented  at  this  level  of  aggregation.  Low- resolution 
models  emphasize  rear  area  operations  that  cannot  be  represented  at  other 
levels  of  resolution.  Such  representation  depends  on  input  from  other  sources 


to  adequately  depict  forward  area  combat  results.  The  fact  that  forward  area 
engineer  operations  score  high  in  the  overall  task  ranking  for  low- resolution 
models  shows  that  the  respondents  believe  these  are  still  important  and  must 
be  accounted  for  even  at  the  level  of  theater-wide  analysis.  This  means  that 
it  is  not  enough  to  examine  only  the  results  provided  by  low-resolution  models 
alone  when  evaluating  how  to  improve  engineer  play  in  low-resolution  models. 
Instead,  the  logic  and  engineer  representation  of  the  models  whose  results 
feed  the  low-resolution  model  must  also  be  evaluated. 

13.  Recommendation .  The  results  of  ESC's  Expert  Judgement  Survey  should 
be  used  as  a  general  outline  from  which  to  develop  much  more  detailed  lists  of 
engineer  tasks  for  individual  models.  Specifically,  the  overall  priorities 
derived  from  the  survey  should  be  used  as  one  input  to  the  allocation  of 
effort  to  improve  engineer  modeling.  Other  factors  to  consider  are  the 
current  status  of  engineer  play  in  each  individual  model,  the  level  of 
representation  of  other  (non-engineer)  functions  in  each  model,  and  the  kinds 
of  analysis  each  model  is  intended  to  support. 
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ENGINEER  TASKS 

1.  Install  Linear  Obstacles  (for  more  detail,  see  FM  5-102).^ 

a.  Conventional  minefields: 

(1)  Anti-tank  mines 

(2)  Anti-personnel  mines 

b.  Scatterable  minefields: 

(1)  Anti-tank  mines 

(2)  Anti-personnel  mines 

c.  Anti-tank  ditches: 

(1)  Rectangular 

(2)  Triangular 

(3)  Sidehill  cut 

d.  Other  linear  obstacles: 

(1)  Anti-tank  wall 

(2)  Concertina  and  barbed  wire 

(3)  Flooding 

(4)  Fire 

e.  Complex  obs  lies  (the  combination  of  several  of  the  above 
obstacles  at  one  location) . 

2.  Install  Point  Obstacles  (for  more  detail,  see  FM  5-102). 

a.  Road  craters: 

(1)  Hasty 

(2)  Deliberate 

b.  Bridge  demolition: 

(1)  Spans 

(2)  Abutments 

(3)  Support  columns 


^Countermob iliCy ,  Field  Manual  (FM)  5-102  (Department  of  the  Army,  March 
1985). 
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c.  Expedient  obstacles: 

(1)  Abatis 

(2)  Log  cribs,  hurdles,  and  posts 

(3)  Rubble 

(4)  Junked  vehicles  and  equipment 

d.  Preconstructed  obstacles: 

(1)  Prechamber  shafts  for  craters 

(2)  Beam  posts 

(3)  Brackets,  chambers,  and  galleries  for  bridge  demolition 

(4)  Falling  block  obstacles 

e.  Atomic  demolition  munitions: 

(1)  Tunnels 

(2)  Major  highways 

(3)  Bridges 

(4)  Narrow  valley  defiles 

3.  Prepare  Fighting  Positions  for  Direct  Fire  Systems  (for  more  detail, 
see  FM  5  - 103) . ^ 

a.  Individual  firing  position: 

(1)  Hasty 

(2)  Deliberate 

b.  Trenches: 

(1)  Crawl  trench 

(2)  Standard  fighting  trench 

c.  Crew-served  weapons: 

(1)  Hasty 

(2)  Deliberate 

d.  Fighting  vehicles: 

(1)  Hasty 

(2)  Deliberate 

4.  Prepare  Positions  for  Indirect  Fire  and  Other  Systems  for  more 
detail  see  FM  5-103)  • 

a.  Artillery  -  parapet 

b.  Air  defense  artillery  -  parapet 

^■Survivability ,  FM  5-103  (Department  of  the  Army,  June  1985). 
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c.  Support  vehicles  and  vans: 

(1)  Deep-cut 

(2)  Covered  deep-cut 

d.  Unit  positions: 

(1)  Bunkers 

(2)  Shelters 

(3)  Protective  walls  and  revetments 

5.  Breach  Obstacles  in  the  Assault  (for  more  detail  see  FM  5-101). ^ 

a.  Minefields: 

(1)  Detection 

(2)  Bypass 

(3)  Force  through 

(4)  Hasty  breach 

(5)  Deliberate  breach 

b.  Obstacles  other  than  minefields: 

(1)  Detection 

(2)  Bypass 

(3)  Force  through 

(4)  Hasty  breach 

(5)  Deliberate  breach 

6.  Improve  Assault  Breaches  for  Follow-on  Forces  (for  more  detail,  see 

FM  5-101). 

a.  Minefields: 

(1)  Proof  lanes 

(2)  Widen  lanes 

(3)  Mark  minefield 

(4)  Minefield  clearing 

b.  Obstacles  other  than  minefields: 

(1)  Widen  lanes 

(2)  Mark  lanes 

(3)  Obstacle  reduction 


■^Mobility,  FM  5-101  (Department  of  the  Army,  January  1985). 
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7.  Conduct  River  Crossing  Operation  in  the  Assault  (for  more  detail,  see 
FM  5-101) • 

a.  Site  reconnaissance 

b .  Bypass 

c .  Ford 

d.  Swim 

e .  Raft 

f .  Armored  vehicle  launched  bridge  (AVLB) 

8.  Improve  River  Crossing  Site  for  Follow-On  Forces  (for  more  detail, 
see  FM  5-101)  • 

a.  Improve  entry,  exit,  and  bottom  at  ford  sites 

b .  Recover  rafts  and  AVLBs 

c .  Emplace  float  bridging 

d.  Emplace  fixed  bridging 

9.  Maintain  Main  Supply  Routes  --  includes  highways  &  railroads  (for 
more  detail,  see  FM  5-104).^ 

a.  Route  reconnaissance 

b .  Road  upgrade 

c .  Construction 

d.  Routine  maintenance 

e .  War  damage  repair 

10.  Pioneer  Trail  Preparation  and  Maintenance  (for  more  detail,  see  FM  5- 

101)  • 

a.  Route  reconnaissance 

b.  Construction 

c .  Camouflage  and  deception 

d.  Routine  maintenance 

e.  War  damage  repair 

11.  Forward  Airlanding  Facility  Preparation  and  Maintenance  (for  more 
detail,  see  FM  5-101)' 

a.  Helicopter  landing  zones: 

(1)  Site  reconnaissance 


^ General  Engineering,  FM  5-104  (Department  of  the  Army,  November  1986). 
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(2)  Construction 

(3)  Camouflage  and  deception 

(4)  Routine  maintenance 

(5)  War  damage  repair 

b.  Forward  arming  and  refueling  points  (FARP) : 

(1)  Site  reconnaissance 

(2)  Construction 

(3)  Camouflage  and  deception 

(4)  Routine  maintenance 

(5)  War  damage  repair 

c.  Low  altitude  parachute  extraction  system  (LAPES) : 

(1)  Site  reconnaissance 

(2)  Construction 

(3)  Camouflage  and  deception 

(4)  Routine  maintenance 

(5)  War  damage  repair 

d.  Landing  strips: 

(1)  Site  reconnaissance 

(2)  Construction 

(3)  Camouflage  and  deception 

(4)  Routine  maintenance 

(5)  War  damage  repair 

12.  Site  Preparation  and  Maintenance  for  CS  and  CSS  Units  (for  more 
detail,  see  FM  5-104). 

a.  Supply  and  maintenance  sites: 

(1)  Site  reconnaissance 

(2)  Construction 

(3)  Camouflage  and  deception 

(4)  Routine  maintenance 

(5)  War  damage  repair 

b.  Ammunition  storage  sites: 

(1)  Site  reconnaissance 

(2)  Construction 

(3)  Camouflage  and  deception 
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(4)  Routine  maintenance 

(5)  War  damage  repair 

c.  Petroleum  pipelines  and  storage  sites: 

(1)  Site  reconnaissance 

(2)  Construction 

(3)  Camouflage  and  deception 

(4)  Routine  maintenance 

(5)  War  damage  repair 

d.  Medical  treatment  sites: 

(1)  Site  reconnaissance 

(2)  Construction 

(3)  Routine  maintenance 

(4)  War  damage  repair 

e.  Prisoner  detainment  sites: 

(1)  Site  reconnaissance 

(2)  Construction 

(3)  Routine  maintenance 

(4)  War  damage  repair 

13.  Rear  Area  Facility  Rehabilitation  and  Maintenance  (for  more  detail, 
see  FM  5-104)' 

a.  Facility  reconnaissance 

b.  Rehabilitation/conversion  of  existing  facilities 

c .  Camouflage  and  deception 

d .  Routine  maintenance 

e .  War  damage  repair 

14.  Airfield  Damage  Repair  (for  more  detail,  see  FM  5-104). 

a.  Reconnaissance/damage  assessment 

b.  Explosive  ordnance  disposal  (EOD) 

c.  Rapid  runway  repair 

d.  Collateral  damage  repair 

15.  Port  and  Waterfront  Facilities  Construction  and  Repair  (for  more 
detail,  see  FM  5-104). 

a.  Breakwaters,  docks,  piers,  wharves,  quays,  moles,  and  landing 


stages : 

(1)  Site/facility  reconnaissance 

(2)  Rehabilitation/conversion  of  existing  facilities 


(3)  Construction 

(4)  Camouflage  and  deception 

(5)  Routine  maintenance 


(6)  War  damage  repair 
Roads  in  the  port  area: 

(1)  Route  reconnaissance 

(2)  Construction 


(3)  Camouflage  and  deception 

(4)  Routine  maintenance 

(5)  War  damage  repair 

Railway  facilities  in  the  port  area: 

(1)  Facility  reconnaissance 

(2)  Rehabilitation/conversion  of  existing  facilities 

(3)  Construction 

(4)  Camouflage  and  deception 

(5)  Routine  maintenance 

(6)  War  damage  repair 
Storage  and  marshaling  areas: 

(1)  Site/facility  reconnaissance 

(2)  Rehabilitation/conversion  of  existing  facilities 

(3)  Construction 

(4)  Camouflage  and  deception 

(5)  Routine  maintenance 

(6)  War  damage  repair 
Port  utilities: 

(1)  Utility  systems  reconnaissance 

(2)  Rehabilitation/conversion  of  existing  facilities 

(3)  Construction 

(4)  Routine  maintenance 

(5)  War  damage  repair 
Tanker  unloading  facilities: 

(1)  Site/facility  reconnaissance 

(2)  Rehabilitation/conversion  of  existing  facilities 

(3)  Construction 

(4)  Camouflage  and  deception 
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(5)  Routine  maintenance 

(6)  War  damage  repair 

g.  Port  fire  fighting  facilities: 

(1)  Site/facility  reconnaissance 

(2)  Rehabilitation/conversion  of  existing  facilities 

(3)  Construction 

(4)  Routine  maintenance 

(5)  War  damage  repair 

h.  Port  support  buildings  and  facilities: 

(1)  Site/facility  reconnaissance 

(2)  Rehabilitation/conversion  of  existing  facilities 

(3)  Construction 

(4)  Camouflage  and  deception 

(5)  Routine  maintenance 

(6)  War  damage  repair 

i.  Logistics  over  the  shore  (LOTS)  sites: 

(1)  Site  reconnaissance 

(2)  Construction 

(3)  Camouflage  and  deception 

(4)  Routine  maintenance 

(5)  War  damage  repair 

j .  Dredging 

k.  Debris  clearance 

16.  Other  (tasks  identified  by  respondents  to  the  survey). 

a .  Engineer  raids 

b .  Nuclear  rubble  removal 
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APPENDIX  F-2 


EXPERT  JUDGEMENT  SURVEY 


EXPERT  JUDGEMENT  SURVEY 
TO  RANK  THE  RELATIVE  IMPORTANCE  OF 
ENGINEER  TASKS  IN  COMBAT  SIMULATIONS 


I.  INTRODUCTION 


1.  PURPOSE.  This  survey  will  collect  the  opinions  of  experienced  officers  and 
modelers  to  help  the  Engineer  Studies  Center  (ESC)  better  define  what  engineer 
tasks  can  and  should  be  represented  in  Army  combat  simulations.  We  want  to  get  a 
wide  variety  of  opinions  to  make  sure  we  consider  all  aspects  of  the  problem  of 
characterizing  engineer  operations  on  the  battlefield. 

2.  Scope .  The  survey  is  organized  into  two  sections. 

A.  Judgement  Criteria.  These  are  factors  that  must  be  considered  in 
ranking  the  importance  of  engineer  tasks.  You  will  be  asked  to  decide  how  much 
weight  each  of  the  judgement  criteria  should  have  in  deciding  the  overall 
priority  of  engineer  tasks  to  include  in  combat  simulations.  The  criteria  are: 

(1) .  LEVEL  OF  SIMULATION 

(HIGH,  MEDIUM  &  LOW  RESOLUTION) 

(2) .  COMBAT  POSTURE 

(DEFENSE  &  OFFENSE) 

(3) .  ENGINEER  RESOURCES 

(MANPOWER  &  EQUIPMENT) 

(4) .  EASE  OF  MODELING 

(EASE  OF  PROGRAMMING  &  AVAILABILITY  OF  INPUT  DATA) 

B.  Engineer  Tasks.  If  you  are  familiar  with  past  engineer  assessments  done 
by  ESC  based  on  Corps,  Army  and  Theater  OPLANS  you  will  see  the  same  philosophy 
of  grouping  engineer  tasks  into  logically  related  increments  was  used  to  develop 
the  categories  for  this  survey.  However,  the  groupings  that  resulted,  while 
similar,  are  not  the  same  as  those  used  in  OPLAN  based  assessments.  For  this 
survey  engineer  operations  are  divided  into  categories  of  similar  tasks  based  on 
the  way  they  interact  with  other  segments  in  combat  simulations.  For  each  of  the 
judgement  criteria  you  will  be  asked  to  rank  order  the  categories  of  engineer 
tasks  based  on  your  opinion  of  the  impact  each  category  has  under  that  criterion. 
The  engineer  task  categories  are: 


(1). 

INSTALL  LINEAR  OBSTACLES 
(MINEFIELDS,  TANK  DITCHES,...) 

(2). 

INSTALL  POINT  OBSTACLES 

(ROAD  CRATERS,  BRIDGE  DEMOLITION,...) 

(3) . 

PREPARE  FIGHTING  POSITIONS  FOR  DIRECT 
(TANKS,  TOWS, . . . ) 

FIRE  SYSTEMS 

(4) . 

PREPARE  POSITIONS  FOR  INDIRECT  FIRE  & 
(ARTILLERY,  ADA,  CPs,...) 

OTHER  SYSTEMS 

(5). 

BREACH  OBSTACLES  IN  THE  ASSAULT 
(BREACH  MINEFIELDS.  SPAN  SHORT  GAPS,., 

.  . ) 
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(6) .  IMPROVE  ASSAULT  BREACHES  FOR  FOLLOW-ON  FORCES 

(CLEAR  MINEFIELDS,  WIDEN  LANES,...) 

(7) .  CONDUCT  RIVER  CROSSING  OPERATION  IN  THE  ASSAULT 

(BANK  CLEARING,  RAFTING,  ASSAULT  BRIDGING,...) 

(8) .  IMPROVE  RIVER  CROSSING  SITE  FOR  FOLLOW-ON  FORCES 

(FIXED  BRIDGING,  FLOAT  BRIDGING,...) 

(9) .  MAINTAIN  MAIN  SUPPLY  ROUTES 

(FILL  CRATERS,  BUILD  UP  WORN  SHOULDERS,...) 

(10) .  PIONEER  TRAIL  PREPARATION  8.  MAINTENANCE 

(ROUTE  CLEARING,  SOIL  STABILIZATION,...) 

(11) .  FORWARD  AIRLANDING  FACILITY  PREPARATION  &  MAINTENANCE 

(AIR  STRIP  CLEARING,  SOIL  STABILIZATION,...) 

(12) .  SITE  PREPARATION  &  MAINTENANCE  FOR  CS  &  CSS  UNITS 

(ACCESS  ROAD,  SITE  CLEARING,...) 

(13) .  REAR  AREA  FACILITY  REHABILITATION  &  MAINTENANCE 

(BUILDING  CONVERSION,  DAMAGE  REPAIR _ ) 

(14) .  AIRFIELD  DAMAGE  REPAIR 

(CRATER  REPAIR,  RUBBLE  CLEARING _ ) 

(15) .  PORT  &  WATERFRONT  FACILITIES  CONSTRUCTION  &  REPAIR 

(PIER  REPAIR,  STORAGE  FACILITY  REHABILITATION,...) 

(16) .  OTHER  (WHILE  THERE  ARE  MANY  OTHER  ENGINEER  TASKS 

PLEASE  ADD  TASKS  ONLY  IF  THEY  ARE  VITAL  TO  MODEL) 


3.  RESPONSES.  The  number  of  different  judgement  criteria  and  engineer  task 
categories  being  considered  make  this  a  rather  long  and  complicated  survey.  In 
the  interest  of  making  the  best  use  of  your  valuable  time  please  answer  as 
thoughtfully  as  you  can  the  portions  of  the  survey  you  feel  you  have  a  good  basis 
of  experience  on  which  to  base  your  answers.  But,  feel  free  to  skip  any  portion 
of  the  survey  where  you  feel  you  lack  the  experience  to  make  good  comparisons  — 
if  you  have  not  been  involved  in  writing  or  using  models  you  need  not  answer 
questions  about  ease  of  programming;  on  the  other  hand,  if  you  are  a  modeler  with 
no  experience  in  combat  engineering  you  need  not  answer  the  questions  about 
combat  posture  and  engineer  resources. 


Your  Name  8.  Grade 


Your  Organization 


Mai!  to:  U.S.  Army,  Engineer  Studies  Center 

ATTN:  CEESC  (Mr.  Stephen  C.  Reynolds) 

Casey  Building  #  2594 

Fort  Belvoir,  Virginia  22060-5583 
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II.  JUDGEMENT  CRITERIA 


4.  LEVEL  OF  SIMULATION.  In  the  hierarchy  of  Army  models  is  it  more  important  to 
play  engineer  operations  in  high  (battal 1  on/company ) ,  medium  (corps/division),  or 
low  ( thcater/army )  resolution  models? 

Consider  how  you  would  answer  that  question  and  then  give  the  percentage  of 
the  engineer  model  improvement  effort  you  think  should  be  devoted  to  improving 


engineer  play  in  i 

each  of 

the 

three 

levels  of 

simul 

at  ion. 

Base 

your 

answers  i 

how  important  you 
resolution. 

th  i  nk 

it  is 
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■  the 

value 

f  of 

engineers 

at 

each  leve 
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5.  COMBAT  POSTURE.  In  combat  simulations  is  it  more  important  to  play  .ngineer 
support  to  the  defense  or  the  offense? 

Consider  how  you  would  answer  that  question  and  then  place  a  vertical  line 
at  the  spot  on  the  scale  that  best  reflects  your  judgement  of  the  relative 
importance  of  playing  engineers  in  the  defense  and  the  offense.  If  you  put  a 
mark  at  the  far  left  it  means  defense  should  be  the  only  consideration  (DEFENSE 
is  100%  and  OFFENSE  is  0%).  If  you  put  a  mark  in  the  center  it  means  defense  and 
offense  are  equally  important  (DEFENSE  is  50%  and  OFFENSE  is  50%).  And  if  you 
put  a  mark  at  the  far  right  it  means  offense  should  be  the  only  consideration 
(OFFENSE  is  100%  and  DEFENSE  is  0%). 
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6.  ENGINEER 

RESOURCES. 

In 

combat 

si  mu 

iations  is  it 

more 

important 

engineer  manpower  or  equipment  requirements? 


Consider  how  you  would  answer  that  question  and  then  place  a  vertical  line 
at  the  spot  on  the  scale  that  best  reflects  your  judgement  of  the  relative 
importance  of  playing  engineer  manpower  requirements  and  engineer  equipment 
requirements.  If  you  put  a  mark  at  the  far  left  it  means  manpower  should  be  the 
only  consideration  (MANPOWER  is  100%  and  EQUIPMENT  is  0%).  If  you  put  a  mark  in 
the  center  it  means  manpower  and  equipment  are  equally  important  (MANPOWER  is  50% 
and  EQUIPMENT  is  50%).  And  if  you  put  a  mark  at  the  far  right  it  means  equipment 
should  be  the  only  c^nsi derat i on  (EQUIPMENT  is  100%  and  MANPOWER  is  0%). 

MANPOWER  100  90  80  70  60  50  40  30  20  10  0 


10  20  30  40  50  60  70  80  90  100 
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EQUIPMENT  0 


7.  EASE  OF  MODELING.  In  combat  simulations  is  it  better  to  add  engineer  tasks 
that  are  easy  to  program  or  tasks  for  which  data  is  easy  to  acquire? 

Consider  how  you  would  answer  that  question  and  then  place  a  vertical  line 
at  the  spot  on  the  scale  that  best  reflects  your  judgement  of  the  relative 
importance  of  choosing  engineer  tasks  to  add  to  simulations  based  on  how  easily 
they  can  be  programmed  or  how  easily  the  input  data  can  be  acquired.  If  you  put 
a  mark  at  the  far  left  it  means  ease  of  programming  should  be  the  only 
consideration  (PROGRAMMING  is  100%  and  DATA  is  0%).  If  you  put  a  mark  in  the 
center  it  means  programming  and  data  acquisition  are  equally  important 
(PROGRAMMING  is  50%  and  DATA  is  50%).  And  if  you  put  a  mark  at  the  far  right  it 
means  data  acquisition  should  be  the  only  consideration  (DATA  is  100%  and 
PROGRAMMING  is  0%). 
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8.  CRITERIA  WEIGHTING.  You  have  rated  the  relative  importance  of  the  categories 
within  each  of  the  four  judgement  criteria  (level  of  simulation,  combat  posture, 
engineer  resources  and  ease  of  modeling).  Now  it  is  necessary  to  decide  the 
relative  importance  of  the  judgement  criteria  themselves. 

In  developing  the  plan  to  prioritize  engineer  model  improvement  efforts  how 
much  weight  should  each  of  the  judgement  criteria  have  on  the  decision? 

Consider  your  answer  to  that  question  and  then  place  a  vertical  line  at  the 
spot  on  each  scale  that  best  reflects  your  judgement  of  the  relative  importance 
of  the  four  criteria. 
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EASE  OF  MODELING 
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III.  ENGINEER  TASKS 


COMBAT  POSTURE  —  IN  HIGH  RESOLUTION  SIMULATIONS 

SCORE  THE  CATEGORIES  OF  ENGINEER  TASKS  BASED  ON 
THEIR  IMPORTANCE  IN  BATTALION/COMPANY  LEVEL  MODELS 

RATE  THE  IMPORTANCE  OF  EACH  CATEGORY  ON  A  SCALE  FROM  1  TO  100  (MOST  IMPORTANT  =  100) 


IMPORTANCE 


IMPORTANCE 


1.  OBST-LN  INSTALL  LINEAR  OBSTACLES 

(MINEFIELDS,  TANK  DITCHES,...) 

2.  OBST-PT  INSTALL  POINT  OBSTACLES 

(ROAD  CRATERS,  BRIDGE  DEMOLITION,...) 

3.  POS-DIR  PREPARE  FIGHTING  POSITIONS  FOR  DIRECT  FIRE  SYSTEMS 

(TAMS,  TOWS,...) 

4.  POS-IND  PREPARE  POSITIONS  FOR  INDIRECT  FIRE  &  OTHER  SYSTEMS 

(ARTILLERY,  ADA,  CPs,...) 

5.  BREACH-AS  BREACH  OBSTACLES  IN  THE  ASSAULT 

(BREACH  MINEFIELDS,  SPAN  SHORT  GAPS,...) 

6.  BREACH- I M  IMPROVE  ASSAULT  BREACHES  FOR  FOLLOW-ON  FORCES 

(CLEAR  MINEFIELDS,  WIDEN  LANES,...) 

7.  RIVER-AS  CONDUCT  RIVER  CROSSING  OPERATION  IN  THE  ASSAULT 

(BANK  CLEARING,  RAFTING,  ASSAULT  BRIDGING,...) 

8.  RIVER- IM  IMPROVE  RIVER  CROSSING  SITE  FOR  FOLLOW-ON  FORCES 

(FIXED  BRIDGING,  FLOAT  BRIDGING,...) 

9.  MSR-MAINT  MAINTAIN  MAIN  SUPPLY  ROUTES 

(FILL  CRATERS,  BUILD  UP  WORN  SHOULDERS,...) 

10.  TRAIL-WPK  PIONEER  TRAIL  PREPARATION  8.  MAINTENANCE 

(ROUTE  CLEARING,  SOIL  STABILIZATION,...) 

11.  FWD-AFLD  FORWARD  AIRLANDING  FACILITY  PREPARATION  &  MAINTENANCE 

(AIR  STRIP  CLEARING,  SOIL  STABILIZATION,...) 

12.  SITE-PREP  SITE  PREPARATION  A  MAINTENANCE  FOR  CS  A  CSS  UNITS 

(ACCESS  ROAD,  SITE  CLEARING,...) 

13.  FACILITY  REAR  AREA  FACILITY  REHABILITATION  &  MAINTENANCE 

(BUILDING  CONVERSION,  DAMAGE  REPAIR,...) 

14.  ADR  AIRFIELD  DAMAGE  REPAIR 

(CRATER  REPAIR,  RUBBLE  CLEARING,...) 

15.  PORT-WRK  PORT  &  WATERFRONT  FACILITIES  CONSTRUCTION  A  REPAIR 

(PIER  REPAIR,  STORAGE  FACILITY  REHABILITATION,...) 


DESCRIBE: _ 

(ADD  TASKS  ONLY  IF  YOU  FEEL  THEY  ARE  VIM  TO  MODEL) 
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16.  OTHER 


COMBAT  POSTURE  —  IN  MEDIUM  RESOLUTION  SIMULATIONS 

SCORE  THE  CATEGORIES  OF  ENGINEER  TASKS  BASED  ON 
THEIR  IMPORTANCE  IN  CORPS/DIVISION  LEVEL  MODELS 


RATE  THE  IMPORTANCE  OF  EACH  CATEGORY  ON  A  SCALE  FROM  1  TO  100  (MOST  IMPORTANT  =100) 


CODE  DESCRIPTION 

OBST-LN  INSTALL  LINEAR  OBSTACLES 

(MINEFIELDS,  TANK  DITCHES,...) 


IMPORTANCE 
IN  DEFENSE 


IMPORTANCE 
IN  OFFENSE 


2.  OBST-PT  INSTALL  POINT  OBSTACLES 

(ROAD  CRATERS,  BRIDGE  DEMOLITION,...) 


3.  POS-DIR  PREPARE  FIGHTING  POSITIONS  FOR  DIRECT  FIRE  SYSTEMS 
(TANKS,  TOWS,...) 


4.  POS-IND  PREPARE  POSITIONS  FOR  INDIRECT  FIRE  &  OTHER  SYSTEMS 
(ARTILLERY,  ADA,  CPs,...) 


5.  BREACH-AS  BREACH  OBSTACLES  IN  THE  ASSAULT 

(BREACH  MINEFIELDS,  SPAN  SHORT  GAPS,...) 


6.  BREACH-IM  IMPROVE  ASSAULT  BREACHES  FOR  FOLLOW-ON  FORCES 
(CLEAR  MINEFIELDS,  WIDEN  LANES,...) 


7.  RIVER-AS  CONDUCT  RIVER  CROSSING  OPERATION  IN  THE  ASSAULT 
(BANK  CLEARING,  RAFTING,  ASSAULT  BRIDGING,...) 


8.  RIVER-IM  IMPROVE  RIVER  CROSSING  SITE  FOR  FOLLOW-ON  FORCES 
(FIXED  BRIDGING,  FLOAT  BRIDGING,...) 


9.  MSR-MAINT  MAINTAIN  MAIN  SUPPLY  ROUTES 

(FILL  CRATERS,  BUILD  UP  WORN  SHOULDERS,...) 


10.  TRAIL-WRK  PIONEER  TRAIL  PREPARATION  &  MAINTENANCE 
(ROUTE  CLEARING,  SOIL  STABILIZATION,...) 


11.  FWD-AFLD  FORWARD  AIRLANDING  FACILITY  PREPARATION  &  MAINTENANCE 
(AIR  STRIP  CLEARING,  SOIL  STABILIZATION,...) 


12.  SITE-PREP  SITE  PREPARATION  &  MAINTENANCE  FOR  CS  &  CSS  UNITS 
(ACCESS  ROAD,  SITE  CLEARING,...) 


13.  FACILITY  REAR  AREA  FACILITY  REHABILITATION  &  MAINTENANCE 
(BUILDING  CONVERSION,  DAMAGE  REPAIR,...) 


14.  ADR  AIRFIELD  DAMAGE  REPAIR 

(CRATER  REPAIR,  RUBBLE  CLEARING,...) 


15.  PORT-WRK  PORT  &  WATERFRONT  FACILITIES  CONSTRUCTION  &  REPAIR 
(PIER  REPAIR.  STORAGE  FACILITY  REHABILITATION,...) 


16.  OTHER  DESCRIBE: _ 

(ADD  TASKS  ONLY  IF  YOU  FEEL  THEY  ARE  VITAL  TO  MODEL) 
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COMBAT  POSTURE  —  IN  LOW  RESOLUTION  SIMULATIONS 


CODE 

1.  OBST-LN 

2.  OBST-PT 

3.  POS-DIR 

4.  POS-IND 

5.  BREACH-AS 

6.  BREACH- IM 

7.  PIVER-AS 

8.  RIVER- Id 

9.  MSR-HAINT 

10.  TRAIL-WRK 

11.  FWD-AFLD 

12.  SITE-PREP 

13.  FACILITY 

14.  ACR 

15. 


SCORE  THE  CATEGORIES  OF  ENGINEER  TASKS  BASED  ON 
THEIR  IMPORTANCE  IN  THEATER/ARMY  LEVEL  MODELS 

RATE  THE  IMPORTANCE  OF  EACH  CATEGORY  ON  A  SCALE  FROM  1  TO  100  (MOST  IMPORTANT  =100) 

IMPORTANCE  IMPORTANCE 

DESCRIPTION  IN  DEFENSE  IN  OFFENSE 

INSTALL  LINEAR  OBSTACLES 

(MINEFIELDS,  TANK  DITCHES _ )  _  _ 

INSTALL  POINT  OBSTACLES 

(ROAD  CRATERS,  BRIDGE  DEMOLITION,...)  _  _ 

PREPARE  FIGHTING  POSITIONS  FOR  DIRECT  FIRE  SYSTEMS 

(TANKS,  TOWS,...)  _  _ 

PREPARE  POSITIONS  FOR  INDIRECT  FIRE  &  OTHER  SYSTEMS 

(ARTILLERY,  ADA,  CPs,...)  _  _ 

BREACH  OBSTACLES  IN  THE  ASSAULT 

(BREACH  MINEFIELDS,  SPAN  SHORT  GAPS,...)  _  _ 

IMPROVE  ASSAULT  BREACHES  FOR  FOLLOW-ON  FORCES 

(CLEAR  MINEFIELDS,  WIDEN  LANES,...)  _  _ 

CONDUCT  RIVER  CROSSING  OPERATION  IN  THE  ASSAULT 

(BANK  CLEARING,  RAFTING,  ASSAULT  BRIDGING,...)  _  _ 

IMPROVE  RIVER  CROSSING  SITE  FOR  FOLLOW-ON  FORCES 

(FIXED  BRIDGING.  FLOAT  BRIDGING,...)  _  _ 

MAINTAIN  MAIN  SUPPLY  ROUTES 

(FILL  CRATERS,  BUILD  UP  WORN  SHOULDERS,...)  _  _ 

PIONEER  TRAIL  PREPARATION  &  MAINTENANCE 

(ROUTE  CLEARING,  SOIL  STABILIZATION,...)  _  _ 

FORWARD  AIRLANDING  FACILITY  PREPARATION  &  MAINTENANCE 

(AIR  STRIP  CLEARING,  SOIL  STABILIZATION....)  _  _ 


SITE  PREPARATION  *  MAINTENANCE  FOR  CS  &  CSS  UNITS 
(ACCESS  ROAD.  SITE  CLEARING,...) 

REAP  AREA  FACILITY  REHABILITATION  &  MAINTENANCE 
( BUILDING  CONVERSION.  DAMAGE  REPAIR....) 

AIRFIELD  DAMAGE  REPAIR 

(CRATER  REPAIR,  RUBBLE  CLEARING. . . . ; 

RCRT  i  WATERFRONT  FACILITIES  CONSTRUCTION  1  REPAIR 
(PIER  REPAIR.  STORAGE  FACILITY  REHABILITATION. . . . ) 


CFSCPi BE: _ 

(ADD  TALKS  ONLY  IF  YOU  FEEL  THEY  ARE  VITAL  TO  MODEL) 
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ENGINEER  RESOURCES  —  IN  HIGH  RESOLUTION  SIMULATIONS 


SCORE  THE  CATEGORIES  OF  ENGINEER  TASKS  BASED  ON 
THE  AMOUNT  OF  ENGINEER  RESOURCES  THEY  REQUIRE 
IN  BATTALION/ COMPANY  LEVEL  MODELS 

RATE  THE  AMOUNT  OF  RESOURCES  REQUIRED  IN  EACH  CATEGORY  ON  A  SCALE  FROM  1  TO  100  (MOST  RESOURCES  =  100) 

AMOUNT  OF  AMOUNT  OF 

CODE  DESCRIPTION  MANPOWER  EQUIPMFjjT 

1.  OBST-LN  INSTALL  LINEAR  OBSTACLES 

(MINEFIELDS,  TANK  DITCHES,...)  _  _ 

2.  OBST-PT  INSTALL  POINT  OBSTACLES 

(ROAD  CRATERS,  BRIDGE  DEMOLITION,...)  _  _ 

3.  POS-DIR  PREPARE  FIGHTING  POSITIONS  FOR  DIRECT  FIRE  SYSTEMS 

(TANKS,  TOWS,...)  _  _ 

4.  POS-IND  PREPARE  POSITIONS  FOR  INDIRECT  FIRE  8,  OTHER  SYSTEMS 

(ARTILLERY,  ADA,  CPs,...)  _  _ 

5.  BREACH-AS  BREACH  OBSTACLES  IN  THE  ASSAULT 

(BREACH  MINEFIELDS,  SPAN  SHORT  GAPS,...)  _  _ 

6.  BREACH- I M  IMPROVE  ASSAULT  BREACHES  FOR  FOLLOW-ON  FORCES 

(CLEAR  MINEFIELDS,  WIDEN  LANES,...)  _  _ 

?.  R1VER-AS  CONDUCT  RIVER  CROSSING  OPERATION  IN  THE  ASSAULT 

(BANK  CLEARING,  RAFTING,  ASSAULT  BRIDGING,...)  _  _ 

8.  RIVER-IM  IMPROVE  RIVER  CROSSING  SITE  FOR  FOLLOW-ON  FORCES 

(FIXED  BRIDGING,  FLOAT  BRIDGING,...)  _  _ 

9.  MSR-NAINT  MAINTAIN  MAIN  SUPPLY  ROUTES 

(FILL  CRATERS,  BUILD  UP  WORN  SHOULDERS,...)  _  _ 

10.  TRAIL-WRK  PIONEER  TRAIL  PREPARATION  8  MAINTENANCE 

(ROUTE  CLEARING,  SOIL  STABILIZATION,...)  _  _ 

11.  FVD-AFLD  FORWARD  AIRLANDING  FACILITY  PREPARATION  l  MAINTENANCE 

(AIR  STRIP  CLEARING,  SOIL  STABILIZATION,...)  _  _ 

12.  SITE-PPEP  SITE  PREPARATION  &  MAINTENANCE  FOR  CS  &  CSS  UNITS 

(ACCESS  ROAD,  SITE  CLEARING,...)  _  _ 

13.  FACILITY  REAR  AREA  FACILITY  REHABILITATION  &  MAINTENANCE 

(BUILDING  CONVERSION,  DAMAGE  REPAIR,...)  _  _ 

14.  ADR  AIRFIELD  DAMAGE  REPAIR 

(CRATER  REPAIR,  RUBBLE  CLEARING,...)  _  _ 

15.  POPT-WPK  PORT  &  WATERFRONT  FACILITIES  CONSTRUCTION  &  REPAIR 

(PIER  REPAIR,  STORAGE  FACILITY  REHABILITATION,...)  _  _ 


16.  OTHER 


DESCRIBE: _ 

(ADD  TASKS  ONLY  IF  YOU  FEEL  THEY  ARE  VITAL  TO  MODEL) 


ENGINEER  RESOURCES  —  IN  MEDIUM  RESOLUTION  SIMULATIONS 

SCORE  THE  CATEGORIES  OF  ENGINEER  TASKS  BASED  ON 
THE  AMOUNT  OF  ENGINEER  RESOURCES  THEY  REQUIRE 
IN  CORPS/DIVISION  LEVEL  MODELS 

RATE  THE  AMOUNT  OF  RESOURCES  REQUIRED  IN  EACH  CATEGORY  ON  A  SCALE  FROM  1  TO  100  (MOST  RESOURCES  =  100) 

AMOUNT  OF  AMOUNT  OF 

CODE  DESCRIPTION  MANPOWER  EQUIPMENT 

1 .  OBST-LN  INSTALL  LINEAR  OBSTACLES 

(MINEFIELDS,  TANK  DITCHES,...)  _  _ 

2.  OBST-PT  INSTALL  POINT  OBSTACLES 

(ROAD  CRATERS,  BRIDGE  DEMOLITION,...)  _  _ 

3.  POS-DIR  PREPARE  FIGHTING  POSITIONS  FOR  DIRECT  FIRE  SYSTEMS 

(TANKS,  TOWS,...)  _  _ 

4.  POS-IND  PREPARE  POSITIONS  FOR  INDIRECT  FIRE  &  OTHER  SYSTEMS 

(ARTILLERY,  ADA,  CPs,...)  _  _ 

5.  BREACH-AS  BREACH  OBSTACLES  IN  THE  ASSAULT 

(BREACH  MINEFIELDS,  SPAN  SHORT  GAPS,...)  _  _ 

6.  BREACH- IM  IMPROVE  ASSAULT  BREACHES  FOR  FOLLOW-ON  FORCES 

(CLEAR  MINEFIELDS,  WIDEN  LANES,...)  _  _ 

?.  RIVER-AS  CONDUCT  RIVER  CROSSING  OPERATION  IH  THE  ASSAULT 

(BANK  CLEARING.  RAFTING,  ASSAULT  BRIDGING,...)  _  _ 

8.  RIVER-IM  IMPROVE  RIVER  CROSSING  SITE  FOR  FOLLOW-ON  FORCES 

(FIXED  BRIDGING,  FLOAT  BRIDGING,...)  _  _ 

9.  MSR-MAINT  MAINTAIN  MAIN  SUPPLY  ROUTES 

(FILL  CRATERS,  BUILD  UP  WORN  SHOULDERS,...)  _  _ 

10.  IRAIL-WRK  PIONEER  TRAIL  PREPARATION  &  MAINTENANCE 

(ROUTE  CLEARING,  SOIL  STABILIZATION,...)  _  _ 

11.  FVD-AFLD  FORWARD  AIRLANDING  FACILITY  PREPARATION  &  MAINTENANCE 

(AIR  STRIP  CLEARING,  SOIL  STABILIZATION,...)  _  _ 

12.  SITE-PREP  SITE  PREPARATION  8,  MAINTENANCE  FOR  CS  8,  CSS  UNITS 

(ACCESS  ROAD,  SITE  CLEARING,...)  _  _ 

13.  FACILITY  REAR  AREA  FACILITY  REHABILITATE  &  MAINTENANCE 

(BUILDING  CONVERSION,  DAMAGE  REPAIR,...)  _  _ 

14.  ADR  AIRFIELD  DAMAGE  REPAIR 

(CRATER  REPAIR,  RUBBLE  CLEARING....)  _  _ 

15.  PCRT-WRK  FORT  &  WATERFRONT  FACILITIES  CONSTRUCTION  8.  REPAIR 

(PIER  REPAIR.  STORAGE  FACILITY  REHABILITATION,...)  _  _ 

16.  OTHER  DESCRIBE: _ 

(ADD  TASKS  ONLY  IF  YOU  FFEL  THEY  ARE  VITAL  TO  MODEL)  _  _ 
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ENGINEER  RESOURCES  —  IN  LOW  RESOLUTION  SIMULATIONS 


SCORE  THE  CATEGORIES  OF  ENGINEER  TASKS  BASED  ON 
THE  AMOUNT  OF  ENGINEER  RESOURCES  THEY  REQUIRE 
IN  THEATER/ARMY  LEVEL  MODELS 

RATE  THE  AMOUNT  OF  RESOURCES  REQUIRED  IN  EACH  CATEGORY  ON  A  SCALE  FROM  1  TO  100  (MOST  RESOURCES  =  100) 


AMOUNT  OF  AMOUNT  OF 


1.  OBST-LN  INSTALL  LINEAR  OBSTACLES 

(MINEFIELDS,  TANK  DITCHES,...) 

2.  QBST-PT  INSTALL  POINT  OBSTACLES 

(ROAD  CRATERS,  BRIDGE  DEMOLITION,...) 

3.  POS-DIR  PREPARE  FIGHTING  POSITIONS  FOR  DIRECT  FIRE  SYSTEMS 

(TANKS,  TOVS,...) 


4.  POS-IND  PREPARE  POSITIONS  FOR  INDIRECT  FIRE  &  OTHER  SYSTEMS 

(ARTILLERY,  ADA,  CPs,...) 

5.  BREACH-AS  BREACH  OBSTACLES  IN  THE  ASSAULT 

(BREACH  MINEFIELDS,  SPAN  SHORT  GAPS,...) 

6.  BREACH- I M  IMPROVE  ASSAULT  BREACHES  FOR  FOLLOW-ON  FORCES 

(CLEAR  MINEFIELDS,  WIDEN  LANES,...) 

?.  RIVER-AS  CONDUCT  RIVER  CROSSING  OPERATION  IN  THE  ASSAULT 
(BANK  CLEARING,  RAFTING,  ASSAULT  BRIDGING,...) 

8.  RIVER-IM  IMPROVE  RIVER  CROSSING  SITE  FOR  FOLLOW-ON  FORCES 

(FIXED  BRIDGING,  FLOAT  BRIDGING,...) 

9.  MSR-MAINT  MAINTAIN  MAIN  SUPPLY  ROUTES 

(FILL  CRATERS,  BUILD  UP  WORN  SHOULDERS,...) 

10.  TPAIL-WRK  PIONEER  TRAIL  PREPARATION  8,  MAINTENANCE 

(ROUTE  CLEARING,  SOIL  STABILIZATION,...) 

11.  FVC-AFLD  FORWARD  AIRLANDING  FACILITY  PREPARATION  S,  MAINTENANCE 

(AIR  STRIP  CLEARING,  SOIL  STABILIZATION,...) 

12.  SITE-PREP  SITE  PREPARATION  &  MAINTENANCE  FOR  CS  &  CSS  UNITS 

(ACCESS  ROAD,  SITE  CLEARING,...) 

13.  FACILITY  REAR  AREA  FACILITY  REHABILITATION  &  MAINTENANCE 

(BUILDING  CONVERSION,  DAMAGE  REPAIR,...) 

14.  ADR  AIRFIELD  DAMAGE  REPAIR 

(CRATER  REPAIR,  RUBBLE  CLEARING,...) 

15.  PORT-VRK  PORT  &  WATERFRONT  FACILITIES  CONSTRUCTION  l  REPAIR 

(PIER  REPAIR,  STORAGE  FACILITY  REHABILITATION,...) 


16.  OTHER  DESCRIBE: _ 

(ADD  TASKS  ONLY  IF  YOU  FEEL  THEY  ARE  VITAL  TO  MODEL) 
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EASE  OF  MODELING  —  IN  HIGH  RESOLUTION  SIMULATIONS 

SCORE  THE  CATEGORIES  OF  ENGINEER  TASKS  BASED  ON 
THE  EASE  OF  MODELING  THEM  IN  BATTALION/COMPANY  LEVEL  MODELS 

RATE  THE  EASE  OF  MODELING  OF  EACH  CATEGORY  ON  A  SCALE  FROM  1  TO  100  (EASIEST  =  100) 

EASE  OF  AVAILABILITY 

CODE  DESCRIPTION  PROGRAMMING  OF  DATA 

1.  OBST-LN  INSTALL  LINEAR  OBSTACLES 

(MINEFIELDS,  TANK  DITCHES,...)  _  _ 

2.  OBST-PT  INSTALL  POINT  OBSTACLES 

(ROAD  CRATERS,  BRIDGE  DEMOLITION,...)  _  _ 

3.  POS-DIR  PREPARE  FIGHTING  POSITIONS  FOR  DIRECT  FIRE  SYSTEMS 

(TANKS,  TOWS,...)  _  _ 

4.  POS-IND  PREPARE  POSITIONS  FOR  INDIRECT  FIRE  &  OTHER  SYSTEMS 

(ARTILLERY,  ADA,  CPs,...)  _  _ 

5.  BREACH-AS  BREACH  OBSTACLES  IN  THE  ASSAULT 

(BREACH  MINEFIELDS.  SPAN  SHORT  GAPS, . . . )  _  _ 

6.  BREACH- IM  IMPROVE  ASSAULT  BREACHES  FOR  FOLLOW-ON  FORCES 

(CLEAR  MINEFIELDS,  WIDEN  LANES,...)  _  _ 

7.  RIVER-AS  CONDUCT  RIVER  CROSSING  OPERATION  IN  THE  ASSAULT 

(BANK  CLEARING,  RAFTING,  ASSAULT  BRIDGING,...)  _  _ 

8.  RIVER-IM  IMPROVE  RIVER  CROSSING  SITE  FOR  FOLLOW-ON  FORCES 

(FIXED  BRIDGING,  FLOAT  BRIDGING,...)  _  _ _ 

9.  MSR-MAINT  MAINTAIN  MAIN  SUPPLY  ROUTES 

(FILL  CRATERS,  BUILD  UP  WORN  SHOULDERS,...)  _  _ 

10.  TRAIL-WRK  PIONEER  TRAIL  PREPARATION  &  MAINTENANCE 

(ROUTE  CLEARING,  SOIL  STABILIZATION,...)  _  _ 

11.  FWD-AFLD  FORWARD  AIRLANDING  FACILITY  PREPARATION  &  MAINTENANCE 

(AIR  STRIP  CLEARING,  SOIL  STABILIZATION,...)  _  _ 

12.  SITE-PREP  SITE  PREPARATION  &  MAINTENANCE  FOR  CS  &  CSS  UNITS 

(ACCESS  ROAD,  SITE  CLEARING,...)  _  _ 

13.  FACILITY  REAR  AREA  FACILITY  REHABILITATION  &  MAINTENANCE 

(BUILDING  CONVERSION,  DAMAGE  REPAIR,...)  _  _ 

14.  ADR  AIRFIELD  DAMAGE  PEPAIR 

(CRATER  REPAIR,  RUBBLE  CLEARING,...)  _  _ 

15.  POPT-WRK  PORT  &  WATERFRONT  FACILITIES  CONSTRUCTION  8,  REPAIR 

(PIES  REPAIR,  STORAGE  FACILITY  REHABILITATION....)  _  _ 

16.  OTHER  DESCRIBE: _ 

(ADD  TASKS  ONLY  IF  YOU  FEEL  THEY  ARE  VITAL  TO  MODEL)  _ 


EASE  OF  MODELING  —  IN  LOW  RESOLUTION  SIMULATIONS 

SCORE  THE  CATEGORIES  OF  ENGINEER  TASKS  BASED  ON 
THE  EASE  OF  MODELING  THEM  IN  THEATER/ARMY  LEVEL  MODELS 

RATE  THE  EASE  OF  MODELING  OF  EACH  CATEGORY  ON  A  SCALE  FROM  1  TO  100  (EASIEST  =  100) 

EASE  OF  AVAILABILITY 

CODE  DESCRIPTION  PROGRAMMING  OF  DATA 

1.  OBST-LN  INSTALL  LINEAR  OBSTACLES 

(MINEFIELDS,  TANK  DITCHES,...)  _  _ 

2.  OBST-PT  INSTALL  POINT  OBSTACLES 

(ROAD  CRATERS,  BRIDGE  DEMOLITION,...)  _  _ 

3.  POS-DIR  PREPARE  FIGHTING  POSITIONS  FOR  DIRECT  FIRE  SYSTEMS 

(TANKS,  TOWS,...)  _  _ 

4.  POS-IND  PREPARE  POSITIONS  FOR  INDIRECT  FIRE  &  OTHER  SYSTEMS 

(ARTILLERY,  ADA,  CPs,...)  _  _ 

5.  BREACH-AS  BREACH  OBSTACLES  IN  THE  ASSAULT 

(BREACH  MINEFIELDS,  SPAN  SHORT  GAPS,...)  _  _ 

6.  BREACH-IM  IMPROVE  ASSAULT  BREACHES  FOR  FOLLOW-ON  FORCES 

(CLEAR  MINEFIELDS,  WIDEN  LANES,...)  _  _ 

7.  RIVER-AS  CONDUCT  RIVER  CROSSING  OPERATION  IN  THE  ASSAULT 

(BANK  CLEARING,  RAFTING,  ASSAULT  BRIDGING, . . . )  _  _ 

8.  RIVER-IM  IMPROVE  RIVER  CROSSING  SITE  FOR  FOLLOW-ON  FORCES 

(FIXED  BRIDGING,  FLOAT  BRIDGING,...)  _  _ 

9.  MSR-MAINT  MAINTAIN  MAIN  SUPPLY  ROUTES 

(FILL  CRATERS,  BUILD  UP  WORN  SHOULDERS,...)  _  _ 

10.  TRAIL-WRK  PIONEER  TRAIL  PREPARATION  &  MAINTENANCE 

(ROUTE  CLEARING,  SOIL  STABILIZATION,...)  _  _ 

11.  FWD-AFLD  FORWARD  AIRLANDING  FACILITY  PREPARATION  &  MAINTENANCE 

(AIR  STRIP  CLEARING,  SOIL  STABILIZATION,...)  _  _ 

12.  SITE-PREP  SITE  PREPARATION  &  MAINTENANCE  FOR  CS  &  CSS  UNITS 

(ACCESS  ROAD,  SITE  CLEARING,...)  _  _ 

13.  FACILITY  REAR  AREA  FACILITY  REHABILITATION  &  MAINTENANCE 

(BUILDING  CONVERSION,  DAMAGE  REPAIR,...)  _  _ 

14.  ADR  AIRFIELD  DAMAGE  REPAIR 

(CRATER  REPAIR,  RUBBLE  CLEARING,...)  _  _ 

15.  PORT-WRK  PORT  &  WATERFRONT  FACILITIES  CONSTRUCTION  &  REPAIR 

(PIER  REPAIR,  STORAGE  FACILITY  REHABILITATION,...)  _  _ 

16.  OTHER  DESCRIBE: _ 

(ADD  TASKS  ONLY  IF  YOU  FEEL  THEY  ARE  VITAL  TO  MODEL)  _  _ 
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ANNEX  G 

MISSIONS  AND  FUNCTIONS  STATEMENT 


DEPARTMENT  OF  THE  ARMY 


REPVT  TO 
ATTENTION  OF 


TRADOC  ANALYSIS  CENTER 
FORT  LEAVENWORTH.  KANSAS  6S027-6200 


MEMORANDUM  OF  UNDERSTANDING 
BETWEEN 

THE  ENGINEER  STUDIES  CENTER  AND 
THE  TRADOC  ANALYSIS  CENTER 


12  June  1936 


SUBJECT:  Engineer  Studies  Center  (ESC)  Officer  with  Duty  Station  at  TRADOC 

Analysis  Center  (TRAC) 


1.  The  purpose  of  this  memorandum  is  to  outline  the  mission,  functions,  and 
operating  procedures  associated  with  assigning  an  ESC  officer  to  the  TRAC 
technical  staff  . 

2.  Background. 

a.  During  October  and  November  of  1985,  a  series  of  messages  were  sent  by 
USAES,  USACE,  and  Fort  Leavenworth,  aLl  in  reference  to  engineer  staffing  at 
TRAC.  As  a  result,  one  initiative  proposed  by  USACE  was  the  assignment  of  an 
engineer  officer  to  ESC,  with  duty  station  at  TRAC.  Following  CAORA's 
concurrence,  an  ODP  authorization  was  moved  by  HQ  USACE  to  ESC.  The  first  ESC 
officer  to  be  located  at  TRAC  has  also  been  identified  (LTC  George  R.  Meador, 
Cdr,  14th  Engr  bn).  The  projected  reporting  date  for  LTC  Meador  is  August 
1986. 


b.  The  primary  objective  of  this  action  is  to  assist  TRAC  in  determining 
and  modeling  the  value  of  engineers  as  members  of  the  combined  arms  team.  A 
secondary  objective  is  to  determine  and  model  the  importance  of  engineers  in 
their  combat  support  and  combat  service  support  roles.  This  will  be  done  by 
improving  the  modeling  of  engineers  within  the  entire  hierarchy  of  Army  models. 

3.  General  Agreement.  It  is  the  collective  belief  of  TRAC,  USAES,  and  USACE 
that  an  officer  assigned  to  ESC  with  duty  at  TRAC  can  be  made  to  work.  The 
officer  will  be  given  the  charter  of  working  50  percent  of  the  time  in  direct 

support  of  TRAC  and  working  the  remaining  50  percent  on  achieving  the  Chief  of 

Engineer's  goal  of  improving  the  representation  of  engineers  within  the 
hierarchy  of  Army  models. 

a.  The  TRAC  work  will  include: 

(1)  Providing  direct  engineer  expertise  in  scenario  development  by 
highlighting  engineer  missions,  establishing  engineer  requirements,  and 
determining  engineer  capabilities. 

(2)  Maintainin':  close  coordination  with  USAES  to  ensure  that  the  latest 

engineer  doc t r i ne /concept s  are  considered  in  the  TRAC  simulations  and  studies. 

(  3 )  Call  nr;  an  I'SAES  is  needed  to  ensure  th.it  the  necessary  engineer  staff 
is  provided  to  :upport  TRAC  requirements,  i.e.,  g  jme  r  s  /  p  1  a  y  e  rs  . 


SUBJECT:  Engineer  Studies  Cencer  (ESC)  Officer  with  Duty  Station  at  TRADOC 

Analysis  Center  (TRAC) 

(4)  In  general,  being  responsible  for  seeing  that  all  TRAC  activities 
include  adequate  consideration  of  engineers. 

b.  The  USACE  work  would  include: 

(1)  Calling  on  the  expertise  available  within  ESC  to  improve  engineer 
modeling  (does  not  include  computer  programming). 

(2)  Being  the  TRAC/USACE  interface  for  all  actions  taken  by  USACE  Field 
Operating  Agencies  in  engineer  modeling. 

(3)  Coordinating  USAES  needs  in  modeling  of  engineers. 

(4)  Working  toward  the  integration  of  engineer  p lay /ac t i vi t ies  in  all 
levels  of  the  hierarchy  of  Army  models  and  fulfilling  the  goals  of  the  Army 
Model  Improvement  Program. 

c.  Implied  within  this  action  is  the  recently  assigned  responsibility  of 
ESC  as  the  center  of  competence  for  engineer  modeling  within  the  Army.  As 
such,  ESC  has  been  charged  with  the  mission  of  furthering  the  Chief  of 
Engineers  desires  to  improve  the  modeling  of  engineers.  In  this  role,  ESC  will 
have  the  responsibility  for  initiating,  coordinating,  and  integrating  all 
engineer  modeling  within  the  direct  linkage  models  that  make  up  the  hierarchy 
of  Army  models. 

4.  Administrative  Agreement. 

a.  Although  the  officer  will  technically  be  assigned  to  ESC,  Fort 
Leavenworth  will  provide  all  of  the  .  dministrative  and  logistics  support 
normally  provided  to  an  officer  of  equal  rank  assigned  to  TRAC. 

b.  Since  the  officer  is  technically  assigned  to  ESC,  the  Commander/ 
Director  of  ESC  will  be  the  rating  officer.  The  CG  TRAC  will  be  the 
intermediate  rater  and  the  CG  USAES  will  be  the  senior  rater. 

5.  This  memorandum  of  understanding  is  formally  agreed  to  by: 


MG  R.  S.  KEM 
Commandant ,  USAES 


/BG  DAVID  M.  MADDOX 
DCC .  TRAC 


MG  NORMAN  DELBRIDGE 
DCG ,  USACE 


ESC-EO 


REPLY  TO 
ATTENTION  OF: 


DEPARTMENT  OF  THE  ARMY 

U.S.  Army  Corps  of  Engineers 
WASHINGTON,  D.C.  20314 


UL, 


SUBJECT:  Engineer  Studies  Center's  Role  in  Engineer  Modeling 


Deputy  Chief  of  Staff  for  Operations 
and  Plans 

ATTN:  DAMO  Pentagon 

Washington,  DC  20310 


1.  I  consider  the  proper  representation  of  engineers  within  the  Army's 
Combat  Models  to  be  of  great  importance  to  both  US  Army  Corps  of  Engineers 
and  the  Total  Army.  Such  representation  requires  integrating  all  aspects 
of  the  engineer  functional  models  interfacing  with  the  Army  Model  Improvement 
Program  (AMIP/.  To  further  these  goals,  I  have  designated  the  Engineer 
Studies  Center  (ESC)  as  the  Center  of  Engineer  Modeling  for  USACE  and  the 
USACE  point  of  contact  for  AMIP. 

2.  In  fulfilling  this  mission,  ESC  will: 

a.  Monitor  and  evaluate  the  representation  of  engineers  within  the 
hierarchy  of  Army  models  and  provide,  in  coordination  with  the  US  Army 
Engineer  School  (USAES),  recommendations  to  the  Army  Models  Committee. 

b.  Provide  primary  USACE  interface  with  the  AMIP  Management  Office 
(AMMO)  and  other  AMIP  participating  organizations  on  matters  relating  to 
Engineer  Modeling. 

c.  Serve  as  the  USACE  point  of  contact  with  the  ARSTAFF  on  all  matters 
pertaining  to  AMIP  Engineer  Modeling. 

d.  Serve  as  USACE  program  manager  for  AMIP  Engineer  Model  improvements 
provided  by  USACE  laboratories. 

3.  The  designation  of  ESC  as  the  Center  of  Engineer  Modeling  within  USACE 
is  intended  to  strengthen  the  engineer  community's  involvement  in  modeling. 
This  designation  does  not  circumvent  the  duties  and  responsibilities  of 
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1.  Purpose .  At  the  completion  of  the  study,  ESC  published  a  draft 
version  of  this  report  that  was  distributed  for  review  and  comment.  This 
annex  lists  those  comments  and  ESC's  responses  (when  required). 

2.  Scope .  This  annex  presents  the  comments  that  ESC  received  from  a 
select  group  of  agencies  interested  in  the  study.  It  not  only  lists  the 
comments  received,  but  presents  responses  by  ESC  to  substantive  remarks  (i.e., 
non-editorial  comments) .  Changes  have  been  made  to  the  report  when  called 
for,  and  are  indicated  as  such.  Many  comments,  though  pertinent,  have  not 
resulted  in  any  changes  to  the  report,  and  are  discussed  in  this  annex  only. 

3.  Disposition  of  Comments.  This  paragraph  presents  the  comments  and 
responses.  The  general  format  will  be  to  list  the  comment  and  the 
organization  making  it,  followed  by  ESC's  response  and  reaction  . 

a.  COMMENT  (Submitted  by  Ops  Analysis  Group,  ROK/US  CFC) :  While 
engineer  representation  in  the  models  we  use  here  is  of  concern,  there  is 
equal  concern  about  how  other  functions  are  represented  (i.e.,  chemical, 
medical,  transportation,  C^I,  helicopter,  etc.).  And  of  even  more  concern  is 
the  representation  of  Joint/Combined  Forces  and  Special  Operations  Forces. 

Our  efforts  to  improve  our  models  have  generally  followed  a  modular  approach. 
Our  version  of  MTM,  for  example,  actually  consists  of  about  300  integrated 
programs  (215,000  lines  of  code).  It  is  hoped  that  as  the  EMIP  progresses, 
that  the  code/logic,  etc.,  will  be  exportable  to  other  models  --  the 
interactive  ones  that  are  used  for  training/exercises.  Despite  the  PR,  JTLS , 
JESS,  etc.,  leave  much  to  be  desired. 

ESC  RESPONSE:  ESC  developed  this  plan  as  a  near-term  fix  to  the 
most  critical  problems  (i.e.,  the  automated  AMIP  models).  Once  EMIP  is 
underway,  ESC  will  refocus  its  attention  to  the  interactive  analytical  and 
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training  simulations.  We  believe  that  improvement':  to  the  fully  automated 
models,  when  completed  and  approved,  can  be  transferred  fairly  easily  to  these 
other  models . 

b.  COMMENT  (Submitted  by  Ops  Analysis  Group,  ROK/US ,  CFC) :  Reading 
through  the  report  (Main  Paper),  when  Digitized  Terrain  discussion  popped  up, 
it  seemed  out  of  place  or  an  after- thought .  On  reading  Annex  E,  particularly 
the  Conclusions  on  pages  E-26  and  E-27,  I  could  not  see  a  basis  for  the  strong 
recommendations  and  conclusions  of  the  Main  Paper.  Suggest  DTD  be  eliminated 
or  be  included  as  a  separate  monograph. 

ESC  RESPONSE:  ESC  recognizes  the  Army's  DTD  requirements 
encompass  far  more  than  the  EMIP  and  has  modified  the  main  paper  to  clarify 
this  position.  Although  Annex  E  will  not  be  dropped,  ESC  plans  to  publish  a 
separate  monograph  on  this  topic. 

c.  COMMENT  (Submitted  by  Ops  Analysis  Group,  ROK/US,  CFC):  Page  A- 
12,  last  sentence  has  something  left  out  --  appears  to  have  no  continuity  to 
page  A-13. 

ESC  RESPONSE:  Corrected. 

d.  COMMENT  (Submitted  by  Ops  Analysis  Group,  ROK/US,  CFC):  Page  C- 
2,  last  sentence  has  something  left  out  --  appears  to  have  no  continuity  to 
page  C-3. 

ESC  RESPONSE:  Corrected. 

e.  COMMENT  (Submitted  by  Ops  Analysis  Group,  ROK/US,  CFC):  Page  C- 
24,  line  11  --  "Management"  should  read  "Model." 

ESC  RESPONSE:  Corrected. 

f.  COMMENT  (Submitted  by  Ops  Analysis  Group,  ROK/US,  CFC):  Page  A- 
22,  5th  line  from  bottom  --  "addition"  should  be  "additional." 

ESC  RESPONSE:  Corrected. 

g.  COMMENT  (Submitted  by  Plans  and  Programs  Office,  CERL) :  ANNEX  B 
(VIC) .  The  enhancements  to  VIC  outlined  in  the  four  phases  in  this  annex  will 
improve  the  engineer  representation  of  this  AMIP  model  significantly.  In  the 


detailed  design  of  these  enhancements,  however,  the  developers  cannot  lose 
sight  of  the  purpose  of  the  model  as  outlined  on  page  B-7.  The  improvements 
in  the  engineer  representation  must  be  consistent  with  the  model's  level  of 
detail  and  purpose.  ESC  must  provide  specific  guidance  on  the  level  of  detail 
desired.  The  authors  of  this  plan  identify  four  very  important  deficiencies 
in  previous  Army  combat  models:  poor  documentation,  poor  response  to  study 
needs,  inconsistent  results,  and  differing  data  assumptions.  The  EMIP  plan, 
however,  does  not  take  the  actions  necessary  to  prevent  the  same  deficiencies 
in  VIC/EFAM: 

(1)  Funds  are  not  allotted  for  documentation.  Page  B-47  (2) 
clearly  states  that  the  funding  for  the  phased  improvements  of  VIC  is  for 
programming  effort  alone  and  specifically  excludes  documentation.  Yet  (3)  of 
that  same  page  states  that  documentation  by  the  programming  agency  is 
required . 

(2)  All  of  the  VIC  phase  descriptions  underestimate  the 
requirements  for  guidance  on  concepts  and  doctrine.  The  doctrinal 
implications  of  coding  assumptions  must  be  monitored  by  a  subject  matter 
expert  (SME)  at  each  stage  of  development  so  that  the  code  has  credibility 
from  the  very  beginning.  ESC  must  establish  a  structure  for  coordinating  the 
efforts . 

(3)  Testing  and  validation  of  the  code  are  essential  to  ensure 
credible  output.  Funds  are  not  allocated  for  this  task.  In  addition, 
validation  of  the  code  should  be  done  by  an  agency  which  is  independent  of  the 
code  developers. 

Because  of  the  very  tight  development  schedule  for  VIC/EFAM,  the 
timing  of  the  preparation  of  the  tactical  decision  rules  (TDR)  is  crucial. 

This  is  mentioned  on  page  B-41  as  a  part  of  Phase  Two,  but  TDRs  must  be 
developed  for  tasks  in  Phases  Three  and  Four  as  well. 

Phase  One  task  G3  (Figure  B-12)  must  be  an  ongoing 
implementation,  with  the  effects  of  night/weather/smoke  on  engineer  task 
performance  integrated  with  the  development  of  the  coding  for  each  of  the 
engineer  tasks. 

In  Phase  Two  (Figure  B-13),  only  degrading  and  damaging  of 
existing  MSRs  can  be  implemented  for  G8  since  general  road  use  will  not  be 
coded  until  Phase  Four. 
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ESC  RESPONSE:  Comments  noted.  Overall  revised  cost  estimates 
are  contained  in  the  main  report.  ESC  will  assure  that  the  appropriate  level 
of  guidance  and  management  is  available. 

h.  COMMENT  (Submitted  by  Plans  and  Programs  Office,  CERL) :  ANNEX  C 
(FORCEM) .  The  time  schedule  for  the  completion  of  work  on  FORCEM  is  too 
short.  We  estimate  that  the  Concepts  Analysis  Agency  (CAA)  will  need  two 
years  to  complete  its  work.  During  that  time,  the  engineer  community  must 
keep  abreast  of  changes  to  ensure  that  the  model  design  will  support  future 
engineer  enhancements. 

ESC  RESPONSE:  A  revised  FORCEM  schedule  is  contained  in  the 

main  report. 

i.  COMMENT  (Submitted  by  Plans  and  Programs  Office,  CERL):  ANNEX  C 
(EFAM) .  In  the  discussion  of  the  three  alternatives  for  developing  an  EFAM, 
two  problems  arise  when  VIC  is  used  as  the  combat  generator.  Alternative  2 
states  that  an  EFAM  based  on  VIC  will  be  difficult  for  the  USAES  to  operate 
and  maintain.  Alternative  3  states  that  VIC  does  not  have  the  terrain 
resolution  to  play  engineers  in  detail. 

VIC  is  an  unwieldy,  data- intensive  model  requiring  sophisticated 
hardware  and  a  large  support  staff,  neither  of  which  is  currently  available  to 
USAES.  This  problem  needs  to  be  addressed  early  in  the  development  states  of 
the  EMIP  program.  The  poor  terrain  resolution  of  the  current  version  of  VIC 
is  as  much  a  problem  for  Alternative  2  as  it  is  for  Alternative  3.  In  order 
to  play  engineers  at  all,  VIC's  terrain  representation  and  movement  algorithms 
must  be  improved,  even  at  the  cost  of  run  time  increases. 

ESC  RESPONSE:  The  combined  EFAM-VIC  program  will  address  this 

problem . 

j  COMMENT  (Submitted  by  Plans  and  Programs  Office  CERL) :  ANNEX  E 
(DIGITAL  TERRAIN  DATA  IN  SUPPORT  OF  LAND  COMBAT  MODELS).  While  this  chapter 
deals  with  the  difficulty  of  obtaining  detailed  terrain  data,  the  use  of  that 
data  in  modeling  more  realistic  movement  of  units  is  not  mentioned.  The 
resolution  of  the  effects  is  as  important  as  the  resolution  of  the  data. 
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For  example,  in  the  present  version  of  VIC,  the  size  of  a  grid 
square,  the  number  of  levels  of  elevation,  and  the  number  of  types  of  ground 
cover  are  not  limited,  but  the  traf f icability  level  determined  by  combinations 
of  elevation,  ground  cover,  and  weather  can  be  only  one  of  three  values: 
good,  fair,  or  poor.  Clearly,  increasing  the  level  of  detail  in  the  terrain 
data  will  yield  a  more  realistic  modeling  of  movement  only  if  there  is  a 
corresponding  increase  in  the  level  of  detail  of  resulting  effects.  This 
study  needs  to  recognize  the  importance  of  linking  what  is  known  about  the 
environment  with  factors  such  as  movement  speed  and  line  of  sight  which  are 
influenced  by  that  environment. 

ESC  RESPONSE:  Annex  E  was  written  to  highlight  the  serious 
problem  the  Army  has  with  obtaining  digital  terrain  data  coverage  to  support 
the  needs  of  both  combat  models  and  weapon  systems.  ESC's  analysis  of  the 
changes  needed  in  how  specific  models  represent  movement  effects  are  addressed 
in  annexes  A  through  D. 

k.  COMMENT  (Submitted  by  Plans  and  Programs  Office,  CERL) :  Page 

25:  EFAM  Pnase  One  includes  "resolution  to  an  individual  piece  of  engineering 

equipment."  This  capability  will  be  in  place  after  Phase  One  changes  to  VIC. 

ESC  RESPONSE:  Corrected. 

l.  COMMENT  (Submitted  by  Plans  and  Programs  Office,  CERL):  Page  B- 

7:  VIC  statistics  should  be  150,000  lines  of  code  (12  million  bytes)  and 

nearly  one  million  bytes  of  data. 

ESC  RESPONSE:  The  paragraph  has  been  revised. 

m.  COMMENT  (Submitted  by  Plans  and  Programs  Office,  CERL):  Figure 
B-7  and  (1)  on  page  B-27:  The  present  version  of  VIC  does  not  allow  dynamic 
request  for  engineer-emplaced  minefields. 

ESC  RESPONSE:  The  paragraph  has  been  revised. 
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n.  COMMENT  (Submitted  by  Plans  and  Programs  Office,  CERL) :  Page  B- 
35:  VIC  does  model  survivability  from  indirect  fire  using  the  same  defensive 
preparation  level  used  for  direct  fire. 

ESC  RESPONSE:  The  paragraph  has  been  revised. 

o.  COMMENT  (Submitted  by  TRAC-FLVN):  Task  G7 ,  "Add  Capability  for 
maneuver  units  to  use  roads,"  is  listed  to  begin  planning  in  Phase  I,  but  be 
completed  in  a  later  phase.  The  priority  of  this  task  needs  elevated 
substantially  due  to  the  possible  methodology  effects  in  areas  such  as  CM3, 

Ml,  and  M5  ("Add  capability  for  dynamic  site  selections  and  emplacements," 

"Add  dynamic  capability  for  engineer  units  to  breach  minefields,"  and  "Add 
dynamic  request  and  capability  for  engineer  units  to  breach  linear 
obstacles").  The  planning  for  G7  needs  to  be  done  in  advance  of  these  tasks 
to  ensure  that  the  proper  data  structures  and  methodologies  are  employed. 

ESC  RESPONSE:  Comment  noted. 

p.  COMMENT  (Submitted  by  TRAC-FLVN):  While  TRAC-FLVN  agrees  that 
sharing  the  cost  of  development  of  the  EMIP  Plan  amongst  the  various  agencies 
listed  on  page  31  is  a  desirable  goal,  this  agreement  does  not  imply  that  TRAC 
has  either  the  funding  or  personnel  to  assist  with  this  effort.  The  one 
manyear  and  $120,000  per  year  cost  share  to  TRAC  for  each  of  FY88  and  FY89 
cannot  be  allocated  by  TRAC-FLVN.  TRAC-WSMR  must  be  the  resource  for  this 
CASTFOREM  effort  via  the  AR  5-5  process. 

ESC  RESPONSE:  Comment  noted. 

q.  COMMENT  (Submitted  by  AMSAA) :  A  general  recommendation  that 
applies  to  at  least  the  VIC  and  FORCEM  engineer  representation  enhancements  is 
that,  parallel  to  the  effort  to  improve  the  scope  and  depth  of  engineer 
representation  in  these  major  analytic  models,  the  ESC  develop  a  more 
abstract,  faster- running  version  for  incorporation  in  both  models  when  the 
analysis  being  performed  does  not  pertain  to  decisions  on  engineer  assets. 
Despite  the  on-going  efforts  to  improve  run  time  (including  a  current  AMSAA 
task  to  adapt  VIC  to  Cray  computers),  there  will  remain  a  need  for  much  more 
responsive  models  than  we  now  have.  This  recommendation  is  somewhat  analogous 
to  combining  the  EMIP  alternatives  2  and  3,  page  D-7. 
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ESC  RESPONSE:  ESC  agrees  with  this  recommendation.  One  goal  of 
the  EMIP  will  be  to  continuously  seek  ways  to  improve  the  responsiveness  of 
the  models . 

r.  COMMENT  (Submitted  by  AMSAA) :  It  is  suggested  that  the  total 
engineer  countermine  effort  will  be  inadequately  represented  if  the  modeling 
accounts  only  for  requests  by  maneuver  unit  (e.g.,  page  B-33,  para  ( 3 ) ( a ) ) . 
Signal,  medical,  logistics,  headquarters  and  other  elements  will  need  frequent 
and  responsive  engineer  assistance  when  they  encounter  Red  FASCAM. 

ESC  RESPONSE:  The  paragraph  has  been  revised. 

s.  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  15, 
Fara  12a,  Line  9.  CAA  has  recently  launched  an  effort  to  emphasize  and 
accelerate  continued  FORCEM  model  development  which  had  suffered  at  the 
expense  of  study  support  activities  for  some  time.  As  a  part  of  this,  program 
model  study  support  will  be  curtailed  by  CY  88,  and  FORCEM  will  not  be  used  in 
support  of  the  OMNIBUS -89  study. 

ESC  RESPONSE:  Changes  have  been  made  to  reflect  this 

development . 

t.  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  18, 
Para  15a(3)(c),  line  3.  Suggest  rewording  to  read  "will  remain  to  be 
addressed"  rather  than  "...is  likely  to  remain  unaddressed." 

ESC  RESPONSE:  Paragraph  has  been  revised. 

u.  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  C-5, 
Para  5,  line  6.  A  Model  Output  document  also  exists,  put  out  at  the  same  time 
as  the  Model  Data  Input  document. 

ESC  RESPONSE:  The  paragraph  has  been  revised. 

v.  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  C-5, 
Para  6,  Line  4.  Computer  description  should  read  "1100/84  computer  having  4 
megawords  ..." 

ESC  RESPONSE:  The  paragraph  has  been  revised. 
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w.  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  C-7, 
Top  of  Page,  2d  Line.  The  procedure  For  collecting  VIC  data  to  support  a 
linkage  with  FORCEM  similar  to  the  present  COSAGE  -  FORCEM  linkage  has  been 
worked  out.  The  programs  to  implement  this  should  be  completed  this  FY. 

ESC  RESPONSF-  Text  has  been  updated. 

x.  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  C-7, 
Para  6c(2),  Line  10.  Considerable  analysis  and  some  preliminary  study  work 
have  been  done  on  the  question  of  a  requirements  mode  of  operation  for  FORCEM. 
However,  an  operational  capability  which  would  do  away  with  FASTALS  is  not 
likely  in  the  next  year. 

ESC  RESPONSE:  Text  revised  to  show  that  this  has  been 
considered,  but  not  solved. 

y.  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  C-7, 
Para  7a,  Line  2.  Arrival  of  units  and  supplies  in  the  theater  are  two  other, 
and  more  important,  external  events. 

ESC  RESPONSE:  Units  and  supply  arrivals  were  implicit  in  the 
arrivals'  reference. 

z.  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  C-9, 
Para  7c,  Line  9.  The  present  placement  of  engineer  operations  as  a  component 
module  of  CSS  operations  is  a  matter  of  FORCEM  logical  program  structure,  and 
not  a  statement  about  the  significance  of  engineer  operations.  It  is  a 
separate  module  which  could  be  invoked  independently  of  CSS. 

ESC  RESPONSE:  Text  has  been  revised  to  remove  connotation  of 
deliberate  slighting  of  engineers. 

aa .  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  C-9, 
Para  8,  Line  9.  Sentence  beginning  "FORCEM  has  relied  on  units..."  is 
confusinglv  worded.  Recommend  something  like,  "Only  units  may  be  detected  and 
attacke'1."  (Work  is  planned  to  change  both  the  unit  data  structure  and  target 
representation. ) 

ESC  RESPONSE:  Text  has  been  changed  to  clearer  statements. 


bb .  COMMENT  (Submitted  by  Director,  FukCEM  Task  Force):  Page  C-10, 
Figure  C-3.  Intelligence,  communication  and  engineer  units  are  also  present 
at  all  levels.  ATAF  (Allied  Tactical  Air  Force)  units  exist  at  the  theater 
level.  Airbases  are  not  at  division  level.  They  may  be  located  anywhere  but 
are  subordinate  to  ATAF  units  at  theater  level.  Explicit  convoys  do  not 
operate  from  the  division  level,  only  from  corps  and  higher  levels.  Task 
Force ) 

ESC  RESPONSE:  Figure  changed  with  corrections  added. 

cc.  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  C-10, 
last  2  sentences.  Terrain  effects  on  engagement  are  represented  indirectly, 
if  very  imperfectly,  through  the  division  level  sample. 

ESC  RESPONSE:  COSAGE  terrain  considerations  are  now  mentioned. 

dd.  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  C-14, 
Para  11,  Line  6.  Recommend  deletion  of  parenthetical  comment  on  CEM. 

ESC  RESPONSE:  Agree. 

}  ee .  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  C-17, 

Para  12b,  Line  1.  The  term  "ignoring"  conveys  a  sense  of  deliberateness.  The 
reason  fo**  absence  of  engineer  representation  is  not  because  the  issue  was 
ignored.  The  whole  paragraph  sounds  a  little  didactic. 

|  ESC  RESPONSE:  ESC  has  changed  some  of  the  wording,  but 

believes  it  must  assume  an  advocacy  role  to  ensure  just  engineer 
representation. 

ff.  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  C-18, 
Para  12b(3),  Line  20.  Is  this  a  strawman;  is  anyone  making  this  argument? 

This  sentence,  and  the  one  preceding,  could  easily  be  dropped. 

ESC  RESPONSE:  This  may  have  been  anticipating  defenses  that 
have  been  used  before  by  others.  In  any  case,  the  language  has  been  changed. 

gg.  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  C-20, 
Para  13a(2) ,  Line  15.  Such  measures  of  installation  size  (and  capability)  as 
t  number  of  beds  or  troops  are  used  for  support  command  units,  which  are  not 
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mentioned  here,  though  they  are  in  the  same  category.  The  point  that  physical 
installation  facilities  are  not  represented  is  correct. 

ESC  RESPONSE:  Comment  noted. 

hh.  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  C-22, 
Para  13a(3)(a),  Line  6.  VIC  is  now  operational  on  the  VAX  8600  at  CAA.  A  VIC 
familiarization  study  is  just  Deing  completed  and  a  COSAGE-VIC  comparison 
study  is  just  starting.  Results  of  this  study  will  help  determine  the 
schedule  for  transition  from  COSAGE  to  VIC. 

ESC  RESPONSE:  Text  changed  to  reflect  new  situation. 

ii.  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  C-26, 
Para  13b(2)  .  This  paragraph  presents  suggestions  for  FORCEM  modeling  changes 
not  directly  concerned  with  engineer  representation.  The  comments  reflect 
changes  already  planned  by  CAA  for  reasons  having  nothing  to  do  with 
engineers.  While  such  comments  are  not  unwelcome,  they  seem  extraneous  to 
this  review. 

ESC  RESPONSE:  Since  the  "unit"  was  the  undoing  of  earlier 
engineer  modeling,  ESC  sought  only  to  make  a  case  for  flexibility  and  side 
benefits . 


j j .  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  C-30, 
Para  14a,  Line  3.  The  question  of  how  to  deal  with  requirements  analysis  in 
FORCEM  has  been  addressed,  though  not  solved.  The  issue  has  not  been 
addressed  with  respect  to  engineers,  however. 

ESC  RESPONSE:  Text  changed  to  indicate  that  problem  has  been 

addressed . 


kk.  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  C-31, 
Para  14e .  This  paragraph  and  the  two  following  present  comments  about 
modeling  which  are  generally  correct,  but  seem  to  be  outside  the  scope  of  this 
review.  More  specific  points  related  to  the  anticipated  tasks  would  be 
better . 


ESC  RESPONSE:  Although  some  rewording  has  been  made,  ESC  still 
feels  compelled  to  caution  designers  and  users  about  logic  and  data  clarity. 


I- 


11.  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  C-31, 
Para  14f.  The  meaning  of  this  paragraph  (or  its  title)  is  not  clear. 

ESC  RESPONSE:  If  FORCEM  only  represents  a  portion  of  engineer 
tasks,  then  interpretation  and  impact  on  force  structure  should  recognize  that 
some  tasks  and  units  are  not  reflected. 

mm.  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  C-32, 
Para  15.  Comments  about  the  shortcomings  of  SIMSCRIPT  are  interesting,  but 
again  seem  somewhat  off  the  subject. 

ESC  RESPONSE:  Comments  are  intended  to  illustrate  that  FORCEM 
can  not  "protect"  or  "hide"  a  submodule. 

nn.  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  C-33, 
Para  18 ,  Line  6 .  This  comment  about  recovery  operations  and  convoys  seems 
gratuitous . 

ESC  RESPONSE:  Comment  shows  engineer  frustration  with 
frequently  being  "not  represented."  A  more  direct  statement  to  this  effect 
has  been  substituted. 

oo.  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  E-23, 
Para  14a,  Line  13.  FORCEM  digitized  terrain  also  exists  for  Korea  and 
Southwest  Asia,  but  has  never  been  used  or  fully  tested  with  the  model. 

ESC  RESPONSE:  The  paragraph  has  been  revised. 

pp .  COMMENT  (Submitted  by  Director,  FORCEM  Task  Force):  Page  E-24, 
Para  14c(l)(a),  Line  10.  POL  pipelines  are  not  necessarily  assumed.  They  may 
be  "turned  off"  by  input. 

ESC  RESPONSE:  The  paragraph  has  been  revised. 

qq.  COMMENT  (Submitted  by  Assistant  Chief  of  Engineers):  I  believe 
the  plan  is  on  target  with  the  recommendation  that  we  must  focus  our  efforts 
on  the  Vector  in  Commander  (VIC)  model.  Upgrading  the  engineer  representation 
in  this  mid-range  model  will  give  us  the  greatest  possible  return  for  our 
efforts.  Most  of  the  plan's  recommended  changes  are  realistic  and  reasonable. 
It  is  essential  that  we  make  these  changes  as  quickly  as  possible.  If  the 
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changes  are  delayed  too  long,  we  Increase  the  risk  that  VIC  will  be  replaced 
or  changed  before  our  ideas  can  be  implemented. 

ESC  RESPONSE:  Agree. 

rr.  COMMENT  (Submitted  by  Assistant  Chief  of  Engineers):  The  EMIP 
Plan  outlines  the  need  to  improve  the  US  Army  engineer  representation  in  the 
US  Army's  models.  The  threat  engineer  representation  must  be  similarly 
improved.  If  the  threat  engineer  forces  are  not  accurately  portrayed,  the 
model  will  not  be  improved.  These  tasks  should  be  explicitly  discussed  in  the 
plan  because  we  need  to  maintain  balance  in  the  models  while  accurately 
representing  the  capabilities  of  both  forces. 

ESC  RESPONSE:  The  EMIP  Plan  does  not  differentiate  between  red 
and  blue  engineer  representation.  Representation  of  the  threat  will  be  given 
a  balanced  treatment. 

ss.  COMMENT  (Submitted  by  Assistant  Chief  of  Engineers):  The  EMIP 
Plan  recommends  ETL  produce  the  digitized  terrain  data  (DTD)  needed  to  improve 
the  terrain  representation  in  the  Army  models.  This  is  a  major  additional 
effort  for  ETL  which  is  already  stretched  thin.  The  plan  estimates  that  this 
new  work  will  require  about  20  people  and  $3  to  $5  million.  In  light  of  the 
austere  years  that  we  face,  I  am  not  sure  that  these  expectations  are 
reasonable . 

ESC  RESPONSE:  Out  of  a  recognition  that  the  Army's  DTD 
requirements  go  far  beyond  the  needs  of  the  modeling  community,  this  plan 
proposes  the  DTD  program  be  separated  from  EMIP.  The  plan  proposed  in  this 
annex  was  developed  in  coordination  with  ETL  and  ESC  recommends  that  ETL 
assume  responsibility  for  the  program.  But,  whether  this  means  ETL  will  do 
the  work  in-house,  by  contract,  or  through  DMA  is  not  certain.  In  fact,  the 
work  done  on  this  annex  has  added  momentum  to  ETL's  efforts  to  persuade  DMA  to 
reexamine  its  position  on  not  producing  interim  terrain  data  to  meet  Army 
needs  before  the  Mark  90  system  becomes  operational. 

tt.  COMMENT  (Submitted  by  Assistant  Chief  of  Engineers):  This  plan 
relies  on  TRADOC  Analysis  Command  (TRAC),  Concepts  Analysis  Agency  (CAA) ,  and 
the  Engineer  School  to  accomplish  critical  aspects  of  the  plan.  TRAC  will 


improve  the  engineer  representation  in  the  high- resolution  CASTFOREM  model, 
and  CAA  will  work  on  the  engineer  Lions  or  the  low-resolution  FORCEM  model. 
The  Engineer  School  will  accept  engineer  family  of  models  for  operation  and 
maintenance.  We  may  need  memorandums  of  understanding  with  all  parties  to 
assure  that  everyone  understands  what  is  expected  from  each  other.  These 
understandings  would  help  us  all  as  we  implement  the  EMIP  Plan  during  a  time 
of  personnel  turbulence. 

ESC  RESPONSE:  Agree.  ESC  has  taken  the  first  step  by  obtaining 
letters  of  support. 

uu.  COMMENT  (Submitted  by  TRAC-WSMR) :  Page  17,  III-15a(l) . 

Although  the  document  is  well  written,  there  is  evidently  some 
misunderstanding  on  how  engineering  operations  are  played  in  CASTFOREM.  There 
is  definitely  an  explicit  play  of  engineering  functions.  Minefields  may  be 
pre-emplaced  or  artillery  delivered.  When  units  pass  through  a  minefield,  a 
one-on-one  encounter  takes  place.  The  current  logic  is  portrayed  in  the 
CASTFOREM  Methodologies  on  pages  3-123.  Explicit  responses  determined  by 
decision  tables  then  can  bring  into  play  any  desired  effects  such  as 
breaching,  bulling,  calling  in  Engineer  units,  slowing  or  stopping  movements, 
going  only  through  cleared  lanes  once  the  minefield  is  breached,  etc. 

ESC  RESPONSE:  Comment  noted.  The  text  describing  engineer 
representation  in  CASTFOREM  has  been  updated  to  correct  any  misunderstanding. 

w.  COMMENT  (Submitted  by  TRAC-WSMR):  Page  A-2,  Footnote. 
CASTFOREM' s  most  extensive  documentation  is  in  the  recently  published  manual 
on  CASTFOREM  Methodologies. 

ESC  RESPONSE:  ESC  has  updated  the  EMIP  Plan  to  reflect  the 
information  published  in  the  five  volumes  of  CASTFOREM  documentation  in 
February,  1988. 

ww .  COMMENT  (Submitted  by  TRAC-WSMR):  Page  A-3,  4b.  4:1  run  times 

are  scenario  -  dependent  and  machine-dependent.  On  a  VAX-8800,  typical  run  time 
to  battle  ratios  are  2:1  or  even  less. 

ESC  RESPONSE:  Corrected. 


xx.  COMMENT  (Submitted  by  TRAC-WSMR) :  Page  A-3,  4c.  We  believe 
CASTFOREM  to  have  the  best  representation  of  Engineering  activities  in  a  model 
of  its  class.  It  may  be  limited  but  only  because  of  the  situation  it  was 
built  to  represent.  TRAC-WSMR  modelers  worked  very  closely  with  the 
Engineering  School  in  developing  the  capabilities  represented  in  CASTFOREM 
(covered  on  Page  A-5,  4g) . 

Vehicles  entering  prepared  fighting  positions  are  afforded  extra 
cover  which,  in  turn,  makes  them  harder  to  hit.  Kill  probabilities  are  not 
degraded.  PK/H  remains  the  same. 

Obstacles,  particularly  minefields,  are  played  explicitly.  A 
vehicle  suffers  damage  only  if  it  detonates  a  mine  and  then  only 
probabilistically.  There  are  no  predetermined  kills  or  times  assessed. 
Breaching  assets  are  played  explicitly  and  are  not  assumed  to  be  available. 

ESC  RESPONSE:  Corrected.  A  footnote  has  been  added  because 
TRAC-WSMR  has  yet  to  publish  the  results  of  their  verification  of  the  decision 
tables  which  support  the  mobility  and  countermobility  in  the  Engineer  Module. 

yy.  COMMENT  (Submitted  by  TRAC-WSMR):  Page  A-4,  Para  4d.  We  are 
not  sure  we  have  reached  the  point  of  approval  by  the  entire  Army  Community, 
but  we  are  trying. 

ESC  RESPONSE:  Corrected. 

zz .  COMMENT  (Submitted  by  TRAC-WSMR):  Page  A-4,  Para  4f.  Several 
other  Government  agencies,  as  well  as  some  contractors,  have  CASTFOREM.  TRAC- 
WSMR  is  the  model  proponent  and,  as  such,  is  responsible  for  model 
configuration  control.  Other  agencies  do  run  CASTFOREM. 

ESC  RESPONSE:  The  reference  regards  model  proponency  has  been 
corrected  in  paragraph  4f.  The  comment  regards  other  agencies  has  been 
reflected  in  paragraph  4i. 

aaa .  COMMENT  (Submitted  by  TRAC-WSMR):  Page  A-5,  Para  4h. 
Minefields  and,  in  fact,  all  of  the  Engineer  tactics  used  in  the 
Countermobility  study  are  already  in  CASTFOREM  and  available  to  be  used  in  all 
studies.  Primarily,  Engineering  tactics  are  modeled  "outside  the  model  code" 
in  generic  decision  tables.  These  decision  tables  may  be  moved  from  study  to 


study,  as  can  other  generic  type  tactical  response  decision  tables  (e.g., 
helicopter  tactics,  fire  suppression,  etc.).  Most  Army  study  scenarios  using 
CASTFOREM  play  minefields.  Thus,  USAES  will  not  have  to  push  for 
modifications,  perhaps,  only  insist  that  minefields  be  included  in  TRADOC 
standard  scenarios. 

ESC  RESPONSE:  ESC  has  updated  the  cited  text  to  indicate 
that  the  countermobility  study  includes  more  than  minefields  and  minefield 
breaching.  Paragraph  4h(2)  was  rewritten  to  show  that  the  TRAC-WSMR  and  USAES 
effort  was  centered  around  generating  appropriate  decision  tables  for 
countermobility  systems  and  testing  CASTFOREM  with  these  decision  tables  in 
place . 


bbb .  COMMENT  (Submitted  by  TRAC-WSMR):  Page  A-8,  Para  6g. 

Artillery  units  may  or  may  not  be  implicitly  prepositioned  in  static  firing 
positions . 

ESC  RESPONSE:  Corrected. 

ccc.  COMMENT  (Submitted  by  TRAC-WSMR):  Page  A-12,  Bottom  of  Page. 
Missing  or  incomplete  sentence. 

ESC  RESPONSE:  Corrected. 

ddd .  COMMENT  (Submitted  by  TRAC-WSMR):  Page  A-13,  Top  of  Page. 
Missing  or  incomplete  sentence. 

ESC  RESPONSE:  Corrected. 

eee.  COMMENT  (Submitted  by  Commander,  BRDEC) :  BRDEC  does  not 
currently  possess  a  running  version  of  the  CASTFOREM  Model  or  Source  Code. 

The  Source  Code  was  requested  from  TRAC  WSMR  on  25  February  1988.  The  US  Army 
Armament  Research  Development  Engineering  Center  (ARDEC)  at  Picatinny  Arsenal, 
Dover,  NJ ,  does  possess  a  running  copy  of  the  model. 

ESC  RESPONSE:  Corrected  in  paragraph  4i. 

fff.  COMMENT  (Submitted  by  Commander,  BRDEC):  The  discussion  of 
CASTFOREM  Model  capabilities  in  Annex  A  is  out  of  date.  For  example,  run 
I  times  per  iteration  with  the  VAX  8800  average  under  two  hours  (reference  page 
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A - 3 ) ;  more  than  one  breached  lane  is  possible  because  it  is  a  user  input 
(reference  page  A-18);  and  RAMMS  can  be  modeled  (reference  page  A-13) . 
Coordination  with  TRAC-WSMR  indicates  they  will  provide  the  information  to 
update  this  Annex. 

ESC  RESPONSE:  Corrected. 

ggg.  COMMENT  (Submitted  by  Commander,  BRDEC) :  Annex  D  (page  D-ll) 
states,  "Engineer  equipment  must  be  identified  at  the  individual  item  level." 
BRDEC  recommends  that  a  list  of  the  specific  systems  that  will  be  modeled  be 
included  in  this  Annex.  It  has  been  our  experience  that  it  is  easier  to  model 
Engineer  Equipment  Systems  while  under  development,  than  after  the  fact. 

ESC  RESPONSE:  Noted.  An  EFAM  Advisory  Group  will  be  organized  to  provide 
detailed  guidance  to  the  model  developers.  Although  not  included  in  the  EMIP 
Plan,  a  list  of  the  specific  systems  to  be  modeled  will  be  included  in 
detailed  Statements  of  Work. 

hhh .  COMMENT  (Submitted  by  Commander,  BRDEC):  In  addition  to 
Engineer  Equipment  Systems  already  fielded,  BRDEC  also  recommends  that  near 
and  midterm  systems  be  included.  The  code,  if  written  in  modular  format,  will 
allow  a  midterm  system  that  is  canceled  before  production  to  be  merely  "turned 
off."  By  including  midterm  systems,  EFAM  will  not  be  obsolete  by  the  time  the 
model  is  finally  completed. 

ESC  RESPONSE:  Agree. 

iii.  COMMENT  (Submitted  by  ETL) :  For  Appendix  E-l,  recommend 
explaining  the  content,  resolution,  accuracy,  and  format  of  each  data  set 
displayed  in  legends.  Also,  why  show  all  possible  data  sets  in  the  legends 
when  only  one  exists  for  an  area?  Showing  one  would  help  clarify  graphics. 

ESC  RESPONSE:  Appendix  E-l  is  provided  as  a  quick  reference, 
to  show  the  individual  and  aggregate  coverage  of  various  data  sets.  The 
details  on  each  data  set  are  documented  in  the  sources  cited  in  the 
bibliography.  The  standard  legend  was  used  to  allow  a  common  coding  pattern 
to  help  the  reader  cross  reference  figures  and  to  simplify  the  graphic  layout 


jjj .  COMMENT  (Submitted  by  ETL) :  Page  E-4,  Para  4,  Line  10.  After 
"specification,"  add  the  phrase,  "as  well  as  identify  Special  Terrain  Data 
(STD)  as  the  Army's  stated  high  resolution  DTD  Requirements.  Both  TTD  and  STD 
will  eventually  serve  as  Army  DTD  sets  of  the  future." 

ESC  RESPONSE:  The  paragraph  has  been  revised. 

kkk.  COMMENT  (Submitted  by  ETL):  Page  E-5,  Para  6,  Line  20.  After 
"DTD",  add  the  word  "source." 

ESC  RESPONSE:  The  paragraph  has  been  revised. 

111.  COMMENT  (Submitted  by  ETL):  Page  E-5,  Para  6,  Line  20. 

Delete  "Army  Field  Units." 

ESC  RESPONSE:  The  paragraph  has  not  been  changed. 

(Paragraph  9  discusses  the  fact  that  field  units  have  limited  capability  to 
produce  DTD.) 


mmm.  COMMENT  (Submitted  by  ETL):  Page  F-6,  Figure  E-l.  For  the 
status  of  DTED  (Level  2),  add  the  word  "very"  in  front  of  "limited." 

ESC  RESPONSE:  The  Figure  has  not  been  revised.  The 
distinction  between  "limited"  and  "very  limited"  is  too  fine  to  appear  in  a 
summary  table  such  as  this. 

nnn.  COMMENT  (Submitted  by  ETL):  Page  E-6,  Figure  E-l.  For  the 
status  of  DFAD  (Level  1-C) ,  add  the  phrase  "limited  coverage"  after  the  word 
"sources . ” 

ESC  RESPONSE'  The  Figure  has  been  revised. 

ooo .  COMMENT:  Page  E-6,  Figure  E-l.  For  the  data  set,  change  the 
word  "WES"  to  "Mobility  Data  Base",  and  place  the  term  "WES"  parenthetically 
underneath  the  phrase,  "Mobility  Data  Base."  Also .  for  the  feature  density, 
change  the  entry,  "100m"  to  25-100m." 

ESC  RESPONSE:  The  Figure  has  been  revised. 


ppp .  COMMENT  (Submitted  by  ETL) :  Page  E-6,  Figure  E-l.  For  the 
status .  add  the  phrase,  "limited  coverage"  after  the  word  "Demonstration." 

ESC  RESPONSE:  The  Figure  has  been  revised. 

qqq .  COMMENT  (Submitted  by  ETL):  Page  E-7,  Para  8. a (2).  1)  TAC 

also  transforms  DTED  to  5  1/4"  Floppy  Disk;  2)  should  a  generic  format  be 
identified  for  ITD,  TaC  will  probably  manage  contracts  for  producing  Digital 
TTADBs ;  3)  support  by  TAC  for  ARTBASS  production  could  be  questionable  since 
CAC  may  cancel  their  requirement  for  additional  DTD  to  support  ARTBASS. 

ESC  RESPONSE:  The  paragraph  has  been  revised. 

rrr.  COMMENT  (Submitted  by  ETL):  Page  E-9,  Para  10.  There  is  no 
mention  of  the  A&E  firms  which  are  better-equipped  than  both  BDM  and  JPL,  for 
DTD  production. 

ESC  RESPONSE:  The  paragraph  has  been  revised. 

sss.  COMMENT  (Submitted  by  ETL):  Page  E-28,  Para  18. c.,  Line  1. 
FORCEM  requires  LOC  networks;  the  majority  of  available  DFAD  (Level  1  1st  Ed) 
does  not  have  LOCs .  Therefore,  availability  of  DMA's  DFAD  to  satisfy  FORCEM 
is  very  limited. 

ESC  RESPONSE:  ESC  agrees  with  the  observation.  No  change 
called  for  in  the  text. 

ttt.  COMMENT  (Submitted  by  ETL):  Page  E-2-3,  Para  27.  ITD 
definition,  while  accurate  for  what  DMA  initially  tried  to  do,  does  not 
accurately  reflect  Army's  current  description  of  ITD  in  general. 

ESC  RESPONSE:  The  definition  has  been  revised. 
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